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Foreword 


Departmental  Policy 


Departmental  Manual  Chapter  376  DM  ]0 
details  policy  concerning  the  life  cycle 
management  of  ADP  Information  Systems, 
and  is  supplemented  by  a  Handbook  that 
addresses  major  application  system  life 
cycle  management.   These  two  documents 
are  in  the  appendices  of  this  Guide. 


Purpose 


This  Guide  provides  detailed  guidance  for 
managing  major  application  system 
development  projects  in  the  Department  of 
the  Interior. 


Intended  Users 


Use 


The  Guide  will  be  used  by  managers  of 
major  application  system  development 
projects  throughout  the  Department. 

A  project  manager  should  read  the  Guide 
carefully  and  adopt  its  approach  to 
developing  major  applications.   If  it  is 
necessary  to  deviate  from  the  standards 
established  by  this  Guide,  the  project 
manager  should  record  the  reason  for  the 
deviation. 


Other  Use 


Term  Definitions 


This  Guide  was  designed  with  major 
applications  in  mind.   While  it  will 
prove  helpful  to  the  managers  of  smaller, 
non-major  applications,  it  should  be 
applied  rigorously  only  to  applications 
that  are  major. 

To  learn  the  definition  of  a  major 
application  and  other  terms  used  in  this 
Guide,  the  reader  should  turn  to  Appendix 
2  at  the  back  of  the  Guide. 


Questions 


Anv  questions  concerning  the  Guide  should 
be  directed  to  the  Office  of  Information 
Resources  Management,  Division  of  Program 
Development  in  Washington;  phone  number 
(202)  343-4281. 


^0 


IX 


A  Project  Manager's  Guide  to 
Application  Systems  Life  Cycle  Management 

TABLE  OF  CONTENTS 
Chapter  1  -  The  Application  System  Life  Cycle 
1.1   Initiation  Phase  7 

A.  Pre-Initiation  Phase  Work  7 

B.  Mission  Analysis  Stage  10 

C.  Concept  Development  Stage 16 

1.  2  Development  Phase  21 

A.  System  Analysis  Stage  22 

B.  System  Design  Stage 26 

C.  System  Construction  and  Acquisition  Stage  30 

D.  User  Acceptance  Stage  34 

1.3  Operation  and  Maintenance  Phase 40 

A.  Implementation  Stage  41 

B .  Maintenance  Stage 45 

Chapter  2  -  Details  of  Project  Management,  Reporting  and  Control 

2.1  Project  Teams  55 

2.2  Project  Initiation 55 

2.3  Project  Reporting  Requirements  60 

2.4  Management  Oversight  of  Projects 67 

2. 5  Milestone  Review  Checklist  ' 68 

Chapter  3  -  Application  Systems  Life  Cycle  Management  Documents 

3.0  Overview  79 

3.1  Initiation  Phase  Documents  81 

3 .  2  Development  Phase  Documents  88 

3.3  Operation  and  Maintenance  Phase  Documents  139 

Appendix  1 

Departmental  Manual  Part  376  DM  10 
Appendix  2 

Application  Systems  Life  Cycle  Management  Handbook 


iii  ■? 


"0"        ...o.i.  '    r^o-^  \,n9X>' 

-.0 


-D^^l'^o*^  SQ^'^' 


■06^- 


ZM^^^^^^^mM 


ggSnali'P^gl^^l^B^^^^S 


Xv-v-^v-vA  PROJECT  MANAGER'S  GUTOE  TO X 
||;>;:APPLICATI0N  SYSTmiS  LIFE  CYCLE  IVIANAGE^/IENT 


^mm^mmmmgm^^mfsmmmi^i^smmmm 


A  Project  Manager's  Guide  to 
Application  Systems  Life  Cycle  Management 


CHAPTER  1 
THE  APPLICATION  SYSTEM  LIFE  CYCLE 


Sfi. 


tt 


CHAPTER  1 

DETAILS  OF 
THE  APPLICATION  SYSTE^i  LIFE  CYCLE 
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Chapter  1 


1.1   Initiation  Phase.   T'he  Initiation  Phase  is  to  perform  those 
mission  process  analysis  activities  necessary  to  investigate 
the  need  for  an  application  system  development  project, 
build  a  blueprint  or  plan  for  the  application,  and  to  decide 
whether  to  proceed  with  defining  detailed  requirements. 
Problems  and  opportunities  are  defined,  mission  requirements 
are  analyzed,  alternative  solutions  are  identified,  and  the 
economic,  technical  and  operational  feasibility  of 
alternatives  is  assessed. 

Note:   The  project  manager  should  keep  in  mind  that  detailed 
functional  and  data  requirements  are  defined  during 
the  Development  Phase.   Initiation  Phase  concentrates 
on  general  application  planning  based  on  need. 

A.   Pre-Initiation  Phase  Work.   Before  the  initiation  phase 
can  begin,  a  requirement  will  be  identified  and 
supported  by  a  functional  (administrative  or 
programmatic)  manager.   The  functional  manager  must 
complete  a  Project  Request,  and  forward  it  to  the 
responsible  information  systems  or  ADP  management  in  the 
agency.   The  Project  Request  will  be  no  more  than  5 
pages  long  and  contain  at  least  the  following: 

(1)  Requestor's  Name  and  Position 

(2)  Need  Statement 

(3)  Need  Impact  or  Cost 

(4)  Mission (s)  Impacted 

(5)  Organizational  Units  Impacted 

(6)  Location  and  Size  of  the  Organizations  Impacted 

(7)  Description  of  the  Work  to  be  Automated 
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MISSION  ANALYSIS  STAGE  RESPONSIBILITY  MATRIX 
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Information  Model  C  R 
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R  =  Responsible  for  Product  Preparation 

C  =  Concurrence  Required 

A  =  Approve 

I  =  Informed  (copy) 
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B.   Mission  Analysis  Stage.   This  stage  is  the  first  of  two 
stages  during  the  Initiation  Phase. 

(1)  Purpose.   T^his  stage  will  result  in  the  user  area 
describing  their  need  for  a  system  in  general 
terms.   Information  about  organization  structure, 
practices  and  information  needs  are  collected  and 
organized  into  models. 

(2)  Objectives.   This  stage  is  intended  to: 

(a)  Identify  mission  needs; 

(b)  Collect  and  present  system  planning 
information; 

(c)  Provide  a  clear  scope  for  an  application 
system  in  lay  terms; 

(d)  Insure  functional  user  management 
participation  in  the  description  of  mission 
needs  and  analysis,  so  that  if  an  automated 
system  results  it  addresses  only  important 
mission  needs;  and 

(e)  Promote  the  uniform  agency  preparation  of 
major  systems  planning  information. 

•  (3)    Activities.   T'hese  standards  apply  to  both  in- 
house  and  contracted  efforts.   The  minimum 
activities  are: 

(a)  Form  a  Project  Management  Committee,  appoint 
an  Application  System  Planning  Project 
Manager,  and  form  an  Application  System 
Planning  Team. 

(b)  Construct  a  model  (graphical  and  textual)  of 
the  organizational  units  impacted  by  the 
proposed  application.   ^^his  is  the 
Organization  Model. 

fc)   Identify  and  describe  the  processes  of  each 
organization.   This  results  in  the  Mission 
Process  Model. 

(d)  Identify  and  chart  the  information  needed  to 
perform  the  processes,  and  chart  the 
information  flow.   This  results  in  an 
Information  Model. 

(e)  Complete  a  Mission  Needs  Statement  (MNS) . 
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(f)  Validate  the  accuracy  of  the  information, 
process  and  orqanization  model  by  having 
functional  management  in  the  impacted  area 
review  the  models. 

(g)  Estimate  the  cost  of  the  Concept  Development 
Stage. 

(h)   Estimate  the  economic  cost  and  justify  the 
expense  for  the  proposed  system. 

(i)   Meet  the  Milestone  0  reporting  requirements. 

Note:   Project  Management  Committee  approval  of  the  MNS 
(pronounced  "mens")  is.  required  before  Concept  Development  Stage 
begins. 

(4)    Mission  Analysis  Stage  Responsibilities. 

(a)   Responsible  functional  manager. 

(i)     Classifies  project  as  a  "major 
application  system." 

(ii)    Establishes  a  Project  Management 

Committee  composed  of  functional  area 
managers  and  ADP  managers. 

(iii)    Identifies  mission  needs  and  submits 
project  request  to  the  Project 
Management  Committee,  and  ADP 
management. 

(iv)    Performs  a  preliminarv  cost  benefit 
analysis. 

(V)     Appoints  a  User  Acceptor.   This 

person  may  serve  as  Project  Manager 
during  Initiation  Phase. 

(vi)    Prepares  a  Project  Charter. 

(vii)    Provides  input  and  resources  to  the 

Project  Manager  during  development  of 
the  work  plan,  and  mission  analysis. 

(viii)  Executes  agreements  to  participate 
with  other  users  in  defining  needs 
and  developing  the  application. 
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(b)  User  acceptor. 

(i)      Participates  in  the  mission  analysis, 
monitors  and  tracks  project  status. 

(ii)     Submits  status  reports  as  required  to 
the  Project  Manager  (if  someone 
else) ,  and  the  Responsible  Functional 
Manager. 

(iii)    Reviews  deliverables,  gives  milestone 
concurrence  in  writing  to  Project 
Manager. 

(iv)     Is  a  prime  candidate  for  Project 
Manager  during  Initiation  Phase. 

(c)  Project  management  committee. 

(i)      Appoints  Project  Manager 

(ii)     Approves  Mission  Needs  Statement  and 
Project  Request,  authorizes 
Initiation  Phase  to  be  completed. 

(iii)    Reviews  project  at  regular  intervals 
during  Mission  Analysis  Stage  and 
reviews  recommendations  at  Milestone 
0.   Authorizes  work  to  begin  on  the 
Concept  Development  Stage,  if 
justified. 

(iv)     Is  responsible  for  ensuring  that  the 
project  manager  meets  the  review 
requirements  of  the  IRMRC. 

(d )  Project  manager. 

(i)      Begins  project  file. 

(ii)     Selects  methodology  to  be  used  for 
mission  analysis.   Business  systems 
planning,  strategic  information 
planning,  and  strategic  systems 
planning  are  methodologies 
appropriate  for  this  work.   If  you 
are  unfamiliar  with  these 
methodologies,  contact  the  Office  of 
Information  Resources  Management  in 
Washington,  for  more  information. 

(iii)    Adapts  ASLC  structure  to  meet  needs 
of  the  project.   Adaptation  is 
reflected  in  a  work  plan. 
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(iv)    Revises  cost  estimates  and  includes 
them  in  cost  benefit  analysis. 

(v)     Assures  that  detailed  project  tasking 
of  all  work  precedes  the  work,  and 
that  a  clear  audit  trail  of  planned 
and  completed  project  tasks  exist. 
Taken  together,  these  project  tasks 
constitute  a  work  plan. 

(vi)    Assembles  resources  for  Initiation 
Phase. 

(vii)    Performs  mission  analysis.   Includes 
determination  of  functional  process 
and  data  requirements;  and 
determination  of  operational  and 
economic  feasibility  of  automation. 
Management  analysts,  data  analysts, 
and  services  of  a  systems  analyst  are 
usually  required. 

(viii)   Performs  A-76  analysis,  and  initiates 
preliminary  procurement  actions  as 
required. 

(ix)  Forwards  approved  Mission  Needs 
Statement  to  Project  Manaqement 
Committee. 

(x)     Prepares  detailed  cost  estimates  for 
the  Concept  Development  Stage. 

(xi)    Recommends  future  actions  to  the  User 
Acceptor  (if  another  person)  and 
Project  Management  Committee. 

(xii)    Learns  and  meet  IRMRC  review 
requirements, 

(5)    Project  File  Documentation. 

(a)   File  maintenance.   Materials  prepared  during 
the  Mission  Analysis  Stage  are  placed  in  a 
project  file.   The  approved  MNS,  Project 
Request,  and  all  ASLC  documentation  materials 
are  retained  for  audits,  reference, 
substantiation,  explanation,  or  clarification 
as  part  of  the  project  file,   fhis  file  will 
be  maintained  throughout  the  ASLC,  and  will 
be  very  large  by  the  time  the  system  is 
operational.   The  Project  Manager  is 
responsible  for  the  orderly  storage  and 
cataloging  of  its  contents. 
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(b)   Documents.   The  following  documents  will  be 

added  to  the  file  during  this  stage.   Chapter 
3  of  this  handbook  contains  information 
regarding  the  document's  contents. 

o  Project  Request 

o  Mission  Analysis  Methodology 

o  Cost/Benefit  Analysis 

o  Project  Charter 

o  Organization  Model 

o  Mission  Need  Statement 

• o  Mission  Process  Model 

o  Information  Model 
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CONCEPT  DEVELOPMENT  STAGE  RESPONSIBILITY  MATRIX 
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C.   Concept  Development  Stage.   n^his  stage  is  the  second  of 
two  stages  in  the  Initiation  Phase.   At  this  point  in 
the  life  cycle  there  is  no  presumption  that  an  automated 
system  is  the  only  solution  to  the  mission  need. 

(1)  Purpose.   A  general  blueprint  of  the  application 
is  prepared  in  this  stage.   This  blueprint  or  plan 
may  divide  an  application  into  one  or  more 
modules,  and  will  be  used  as  the  basis  for  the 
work  of  the  Development  Phase.   The  architectural 
planning  that  is  done  in  this  phase  are  mission, 
information  and  location-oriented,  not  technical 
ADP  architectures. 

(2)  Objectives. 

(a)  Prepare  system  planning  information, 
including  systems,  data  and  data 
communications  plans,  , 

(b)  Provide  a  clear  scope  for  an  application 
system  in  lay  terms. 

(c)  Insure  the  system  plan  addresses  only 
important  mission  needs. 

(d)  Propose  a  system  life  cycle  strategy. 

(e)  Obtain  a  go/no  go  decision  to  begin  System 
Analysis  Stage. 

(3)  Activities.   These  standards  apply  to  both  in- 
house  and  contracted  efforts.   The  minimum 
activities  are: 

(a)  Complete  a  functional  system  architectural 
plan  to  serve  as  a  blueprint  for  system 
development; 

(b)  Complete  a  data  architectural  plan  to  serve 
as  a  high-level  data  base  blueprint; 

(c)  Define  a  general  data  communications 
blueprint; 

(d)  Review  and  revise  the  MNS  done  during  Mission 
Analysis  Stage; 

(e)  Complete  a  system  life  cycle  strategy  (plan) ; 

(f)  Revise  cost/benefit  figures; 
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(g)   Document  the  management  objectives  of  the 

proposed  system,  including  details  that  can 
be  validated  during  system  test  stage. 

(h)   Document  and  retain  the  agreements  reached 
between  participating  organizations  with 
respect  to  their  involvement  in  the 
application  project. 

(i)   Prepare  System  Decision  Paper  for  the 
Milestone  1  review. 

.(4)    Concept  Development  Stage  Responsibilities. 

(a)  Project  manager. 

(1)    Responsible  for  seeing  the  activities 
of  this  phase  are  completed. 

(ii)    Assures  that  work  planning  and  control 
is  done  by  a  tasking  method,  and  that 
a  clear  audit  trail  exists, 

(iii)   Maintains  the  project  file,  and 

updates  it  with  ASLC  documentation 
required  in  this  stage. 

(iv);   Reports  results  to  the  Project 

Management  Committee  at  Milestone  1. 

(v)    Responsible  for  meeting  any  review 
requirements  of  the  IRMRC. 

(b)  User  acceptor. 

(i)    Prepares  a  detailed  description  of  the 
management  objectives  of  the  system. 

(ii)    Participates  daily  in  the  preparation 
of  the  work  products  of  this  stage. 
Might  be  the  Project  Manager. 

(c)  Project  management  committee. 

(i)    Reviews  documentation  presented  for 
Milestone  1.   Recommends  approval  to 
begin  Development  Phase. 

(ii)    Appoints  a  Project  Manager  for  the  ADP 
Project  Team. 

(iii)   Assures  that  the  Project  Management 
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Committee  has  members  representing  all 
areas  impacted  by  the  proposed 
system.   If  necessary,  new  members  are 
added. 

(iv)    Obtains  written  documentation  of  all 
inter-organizational  agreements 
required  to  support  the  project. 

(5)    Project  File  Documentation. 

(a)  File  maintenance.   Materials  prepared  during 
the  Concept  Development  Stage  are  added  to 
the  project  file.   The  Project  Manager  is 
responsible  for  the  orderly  storage  and 
cataloging  of  its  contents. 

(b)  Documents.   The  following  documents  will  be 
added  to  the  file  during  this  stage.   Chapter 
3  of  this  handbook  contains  information 
regarding  the  document's  contents. 

o  System  Objectives 

o  System  Architecture 

o  Data  Architecture 

o  Data  Communications  Architecture 

o  System  Life  Cycle  Strategy 

o  System  Milestone  Dates 

o  System  Life  Cvcle  Resources 
Estimates 

o  Revised  Cost/Benefit  Analysis 

o  Revised  Mission  Need  Statement 

o  System  Decision  Paper  1 
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SYSTEM  ANALYSIS  STAGE 
RESPONSIBILITY  MATRIX 
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1.2   Development  Phase.   There  are  4  stages  in  Development  Phase, 
the  first  being  the  detailed  system  analysis. 

A.   System  Analysis  Stage.   This  stage  is  the  first  stage  in 
developing  or  acquiring  application  software.   If  a 
prototyping  technique  is  used  to  define  requirements, 
the  activities  listed  here  will  be  greatly  changed,  but 
the  reporting  documents  will  remain  much  the  same. 

(1)  Purpose.   System  Analysis  Stage  is  to  identify  and 
document  a  comprehensive  analysis  of 
requirements.   During  the  analysis  stage  the 
functional  requirements  are  defined  in  more 
detail;  i.e.,  system  input,  functional  tasks,  and 
outputs.   This  process  takes  place  at  the 
functional  level,  in  that  the  system  is  described 
in  terms  of  the  detailed  functions  or  tasks  to  be 
performed,  not  in  terms  of  computer  programs, 
files  and  runstreams.   The  emphasis  of  this  stage 
is  on  determining  "what"  tasks  must  be  performed, 
not  "how"  to  perform  those  functions. 

(2)  Objectives.   The  Analysis  Stage: 

(a)  Identifies  the  detailed  functions  and  data  in 
the  current  system; 

(b)  Identifies  deficiencies  in  the  current 
detailed  system  functions;  and 

(c)  Builds  a  data  dictionary/directory  of  current 
system  data  and  reporting  requirements;  and 

(d)  Defines  new  system  requirements  in  terms  of 
functions  and  data. 

(3)  Activities.   The  effort  and  level  of  detail  are  to 
be  commensurate  with  the  size,  complexity,  and 
importance  of  the  system.   These  standards  apply 
to  both  in-house  and  contracted  efforts. 
Activities  are: 

(a)  Describe  the  current  system  in  functional 
flow  terms; 

(b)  Analyze  deficiencies  in  the  current  systems 
and  propose  solutions  to  the  deficiencies; 

(c)  Develop  detailed  functional  requirements; 

(d)  Begin  development  of  a  logical  data  model; 
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(e)  Document  the  analysis  stage  activities  and 
results;  and 

(f)  Identify  data  elements  needed  to  support 
mission  information  requirements.   Cite 
applicable  laws  and  regulations  for  each  data 
element  or  report. 

(4)    System  Analysis  Stage  Responsibilities. 

(a)  User  acceptor.   Reviews  deliverables  and 
gives  milestone  concurrence,  in  writing,  to 
project  manager. 

(b)  Project  manager.   Directs  the  following 
activities. 

(i)    Analysis  of  the  current  system  gaining 
a  detailed  understanding  of  the 
functions  performed  by  the  present 
manual  or  automated  system.   Review  of 
information  flows;  identifying  system 
outputs,  interfaces,  inputs,  stored 
data,  processes,  controls,  and 
backup/recovery/security  procedures. , 
Compiles  a  glossary  of  data 
definitions  and  stores  them 
electronically  in  a  data 
dictionary/directory.   Services  of  a 
systems  analyst  and  data  administrator 
usually  required. 

(ii)    Develop  most  of  functional  system 

specifications.   Definition  of  system 
inputs;  defines  format,  type,  purpose, 
use,  content,  sequence,  retention, 
validation  criteria,  security  and 
other  controls.   Defines  the  "stored 
data"  reauired  by  the  system; 
determines  the  logical  structure  of 
the  data  by  identifying  entities, 
attributes  and  relationships  between 
entities;  defines  privacy 
requirements,  such  as  access  controls 
and  physical  security  requirements. 
Defines  the  process,  both  manual  and 
automated,  required  to  produce  system 
outputs  from  "stored  data"  and  inputs; 
documents  processing  logic  using 
narrative  descriptions,  flow  charts 
and/or  decision  tables.   Defines 
system  outputs;  reports,  CRT  screens, 
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etc.;  identifies  format,  content, 
purpose,  use,  volume,  frequency  and 
distribution  controls.   Services  of  a 
systems  analyst  and  data  administrator 
are  usually  required. 

(iii)   Determines  general  data  conversion 
strategy,  user  acceptance  criteria, 
and  installation  strategy.   Defines 
relative  responsibilities  of  user  and 
ADP  project  development  team. 

(iv)    Updates  work  plan. 

(V)     Reviews  and  approves  deliverables 
produced  as  a  result  of  analysis 
phase. 

(vi)    Obtains  end-of-stage  concurrence  from 
User  Acceptor. 

(vii)   Ensures  that  deliverables  are  updated, 
as  necessary,  based  on  findings  of 
analysis  stage. 

(viii)  Assures  that  work  begins  on  the 
logical  data  model. 

(5)    Project  File  Documentation. 

(a)  File  maintenance.   Materials  prepared  during 
the  System  Analysis  Stage  are  placed  in  a 
project  file.   The  Project  Manager  is 
responsible  for  the  orderly  storage  and 
cataloging  of  its  contents. 

(b)  Documents.   The  following  documents  will  be 
added  to  the  file  during  this  stage.   Chapter 
3  of  this  handbook  contains  information 
regarding  the  document's  contents. 

o  Current  System  Description 

o  Detailed  Functional  Requirements 

o  Data  Requirements 
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B.   System  Design  Stage. 

(1)  Purpose.   T^he  second  stage  of  application 
development  follows  System  Analysis  (or 
prototyping) .   Even  if  an  application  software 
package  is  acquired,  much  of  the  work  in  this 
staged  is  needed.   Functional  specifications  are 
translated  into  system  requirements  for  software 
packages,  hardware  and  communications  facilities 
and  designs  for  computer  programs,  modules,  data 
base(s),  intermediate  files,  and  manual  controls 
and  procedures.   The  application  software  solution 
is  designed  for  the  logical  requirements 
determined  in  the  analysis  stage. 

(2)  Objectives. 

(a)  Design  a  system  that  meets  the  functional 
requirements,  and 

(b)  Plan  for  system  development. 

(3)  Activities.   These  standards  apply  to  both  in- 
house  and  contracted  efforts.   The  activities  are: 

(a)  Evaluate  design  alternatives; 

(b)  Propose  a  system  design? 

(c)  Prepare  a  revised  logical  data  model,  and  a 
data  base  design; 

(d)  Prepare  a  detailed  plan  showing  milestones, 
tasks,  schedule  and  resources  for  developing 
and  implementing  the  proposed  system;  and 

(e)  Document  the  design. 

(4)  Responsibilities. 

(a)   User  acceptor. 

(i)     Participates  in  preparing  mid-project 
review. 

(ii)    Determines  need  for  user 

procedure/training  handbooks  or 
manuals,  and  begins  planning  for  their 
production. 

(iii)   Assists  Project  Manager  in  preparation 
of  test  plan  and  data  conversion 
strategy. 
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(b)   Project  manager.   Directs  the  following 
activities. 

(i)    Development  of  overall  systems 

design.   Updates  logical  data  base 
design?  factors  system  into  a  series 
of  subsystems  and  computer  programs, 
as  necessary?  definition  of  purpose, 
inputs,  processes,  outputs  and 
execution  sequence  for  programs; 
definition  of  logical  data  base  design 
and  define  control  procedures  for  data 
base  backup  and  recovery,  file 
retention,  data  entry,  security 
features,  offline  processing  and  data 
output.   Services  of  systems  analyst, 
senior  programmer,  data  administrator 
and  data  base  administrator  are 
usually  required, 

fii)    Expands  upon  data  conversion  strategy 
addressed  in  analysis  stage.   Develops 
manual  and  automated  reauirements  for 
converting  data  from  present  form  to 
required  form;  defines  specific 
responsibilities  of  user  and  the 
project  development  team. 

(iii)   Identifies  edits  and  internal  control 
requirements  to  ensure  data 
integrity.   Also  ensures  that  an 
adeauate  audit  trail  and  audit 
capability  exists  in  the  application 
system. 

(iv)    Develop  the  test  plan  for  testing 

individual  programs  and  the  overall 
system.   Test  plan  will  address 
internal  testing  for  programs  (using 
such  techniques  as  structured 
walkthroughs,  debugging  aids,  etc.); 
unit  testing  to  ensure  that  program 
performs  in  accordance  with  external 
specifications;  integrated  system 
testing  to  ensure  that  programs 
interface  properly  and  that  required 
functions  are  performed;  and  user 
acceptance  testing  to  ensure  that  the 
user's  formal  criteria  for  acceptance 
are  satisfied. 
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(v)     Define  internal  structure  of  each 

program  in  sufficient  detail  to  enable 
coding  to  take  place.   'T'his  step  will 
be  minimal  if  packaged  software  is 
being  used. 

(vi)    Updates  work  plan. 

fvii)   Reviews  and  approves  deliverables 
produced  as  a  result  of  the  design 
stage. 

(viii)  Prepares  a  mid-project  review  report, 

(ix)    Obtains  end-of-stage  concurrence  from 
User  Acceptor  and  Project  Management 
Committee. 

(5)   Project  File  Documentation. 

(a)  File  maintenance.   Materials  prepared  during 
the  System  Design  Stage  are  placed  in  a 
project  file.   "The  Project  Manager  is 
responsible  for  the  orderly  storage  and 
cataloging  of  its  contents. 

(b)  Documents .   The  following  documents  will  be 
added  to  the  file  during  this  stage.   Chapter 
3  of  this  handbook  contains  information 
regarding  the  document's  contents. 

o  Design  Proposal 

o  Detailed  Cost/Benefits  Analysis 

o  Revised  Life  Cycle  Strategy 

o  System  Decision  Paper  2 
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C.  System  Construction  and  Acquisition  Stage. 

(1)  Purpose.  Develop  all  application  and  conversion 
programs,  perform  initial  internal  and  unit  testing, 
and  system  testing. 

(2)  Objectives. 

(a)  Acquire  hardware,  data  communications,  and 
system  software; 

(b)  Prepare  application  software; 

(c)  Prove  the  system  is  ready  for  production. 

(3)  Activities.  These  standards  applv  to  both  in-house 
and  contracted  efforts.  The  tasks  are: 

(a)  Select,  acquire  and  test  equipment,  data 
conramications ,  and  system  software; 

(b)  Assure  that  the  site  will  be  ready  and 
available; 

(c)  Acquire  or  develop  the  application  software; 
and 

(d)  Document  the  acquisition  and  development 
activities. 

(4)  Systgn  Construction  Responsibilities. 

(a)  Project  manager .  Directs  the  following 
activities. 

(i)    Establishes  the  techniques  and 

conventions  to  be  followed  to  pronote 
consistency,  uniformity  and  quality. 
Ensures  that  standards  are  followed. 

(ii)   Data  structures  creation  and  testing. 

(iii)  Programming  and  developnent  testing. 

(iv)   Installation  of  software  packages, 
security  features  and  establishes 
comiunications  network. 

(v)    Performance  of  technical  and  unit 
testing . 
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(vi)   Prcx3uction  of  operating  instruction 
inanuals. 

(vii)  System  test  planning. 

(5)   Project  File  Documentation. 

(a)  File  maintenance.  Materials  prepared  during 
the  System  Construction  and  Acquisition  Stage 
are  placed  in  a  project  file.  Tlie  Project 
Manager  is  responsible  for  the  orderly  storage 
and  cataloging  of  its  contents. 

(b)  Documents.  The  following  documents  will  be 
added  to  the  file  during  this  stage.  Chapter  3 
of  this  handbook  contains  information  regarding 
the  documents'  contents. 

o  ADPE  Specifications 

"   o  Application  Software 
Documentation 

o  System  Test  Plan 

o  Ccxitrol,  Backup  and  Security  Summary 


32 


I 


33 


The  Application  System  Life  Cycle 
Chapter   1 


User  Acceptance  Stage 
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D. 

User  Acceptance  Stage. 

(1)  Purpose.   Prepare  the  system  for  implementation 
after  it  is  tested  thoroughly. 

(2)  Objectives 

(a)  Assure  the  system  meets  user  functional  and 
data  requirements. 

(b)  Complete  all  required  documentation  that  is 
not  yet  done. 

(c)  Assure  future  system  changes  are  well  managed 
and  documented. 

(d)  Meet  the  standards  of  the  ADP  operations  and 
maintenance  area(s)  (system  custodians),  so 
that  system  operation  can  begin. 

(3)  Activities 

(a)  System  test.   Performed  to  determine  the 
acceptability  of  the  system's  functioning  and 
data  to  the  system  users. 

(b)  User  acceptance.   Obtain  written  sign-off  by 
the  User  Acceptor.   This  sign-off  indicates 
that  the  functions  and  data  provided  by  the 
system  meet  the  users  requirements.   The  user 
area  does  not  assume  system  stewardship  at 
this  time. 

(c)  Generate  production  initiation  notice. 
Nofify  all  organizations  affected  by  the 
system  implementation  date.   State  how  it 
affects  them,  and  what  they  must  do  for 
preparation.   The  operation  organization 
concurs  on  the  established  implementation 
data.   The  notice  will  include: 

(i)     Schedule.   Give  the  date  and  time  for 
system  implementation  and  phased 
activities,  including  any  parallel 
operations  that  are  planned. 

(ii)    Effect.   Give  a  summary  of  the  effects 
of  the  new  system,  and  explain  the 
differences  between  the  old  and  new 
systems. 
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(iii)   Coordination.   Specify  what  activities 
must  be  completed  by  the  users  to 
assist  in  system  implementation, 
including  training  system  users. 

(iv)    Contacts.   List  personnel  contacts  for 
the  system. 

(d)  Prepare  software  change  control  procedures. 
These  procedures  will  be  used  after  system 
acceptance.   Software  control  procedures  are 
used  to:   Maintain  software  integrity; 
minimize  life  cycle  software  costs;  prevent 
unnecessary  or  marginal  changes;  establish 
change  priorities;  assure  prompt  action  on 
changes;  document  the  changes;  and  control 
the  release  of  changed  software  and 
documentation. 

(e)  Prepare  user  training  material. 

(f)  Obtain  production  acceptance.   The  system  is 
considered  operational  and  no  longer 
developmental  after  production  acceptance  by 
the  system's  custodians.   The  custodians  will 
be  responsible  ADP  management  officials,  even 
if  the  operation  function  is  performed  by 
contract  personnel.  Transferring  operational 
responsibility  includes: 

(i)    Production  simulation.   Operations 
personnel,  in  addition  to  equipment 
and  vendor  software  training,  will  be 
trained  to  run  the  applications 
system.   Before  transferring  the 
operational  responsibility,  ADP 
development  and  user  personnel  ensure 
that  operations  personnel  can 
efficiently  and  effectively  run  the 
system,  including  restart,  recovery, 
and  backup.   Evaluate  the  system's 
capability,  emphasizing  actual  and 
potential  problems,  and  prepare  a 
recommendation  relative  to 
transferring  the  system  to  an 
operational  mode. 

(ii)    Documentation.   Make  a  documentation 
needs  assessment.   Show  the  status  of 
vendor  reference  and  operating 
documentation  and  evaluate  the 
Operation  and  User  Manuals.   Identify 
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deficiencies  and  make  reccsnmendations. 

(iii)  Contacts .  Prepare  a  list  of  contacts, 
giving  name,  hone  and  office  telephone 
numbers,  alternate  personnel,  and 
authority  level.  ADP  and  user 
personnel  will  use  these  contacts  for 
problems  and  energencies. 

(iv)   Approvals.  List  the  officials  required 
to  approve  the  production  initiation, 
and  obtain  their  signatures. 

(v)    Implementation  date.  State  the  time 
and  date  of  the  first  production  run, 
special  conditions,  and  the  personnel 
who  are  on  call  or  who  will  be  present 
for  the  start-up. 

(g)  Prepare  operation  instructions.  These 

instructions  are  for  running  the  application 
svstem;  personnel  should  already  be  trained  on 
the  operation  of  the  equipment,  operating 
system,  peripheral  devices,  and  non- 
application  software. 

(4)  Responsibilities. 

(a)  Project  manager  is  responsible  for  assuring 
that  all  activities  in  this  stage  are 
canpleted  before  the  system  goes  to  Operation 
Stage,  and  that  documentation  in  the  Project 
File  is  complete. 

(b)  User  acceptor.  Certifies  that  the  application 
system  performs  according  to  the  users 
functional  and  data  requirenents. 

(c)  Project  managgnent  conmittee  reviews  the 
report  of  the  project  manager,  and  approves 
the  implementation  of  the  system. 

(5)  Proiect  File  Documentation 

(a)  File  maintenance.  Materials  prepared  during 
the  User  Acceptance  Staae  are  placed  in  a 
project  file.  The  Project  Manaaer  is 
responsible  for  the  orderly  storage  and 
cata]oging  of  its  contents. 
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(b)   Documents.   The  following  documents  will  be        V 
added  to  the  file  during  this  stage.   Chapter      ~ 
3  of  this  handbook  contains  information 
regarding  the  documents'  contents. 

o  System  Acceptance  Report 

o  Implementation  Plan 

o  Conversion  Plan 

o  User  Training  Plan 

o  Post  Implementation  Review  Plan 

o  Data  Processing  Manual 

o  User  Manual 

o  Operations  Manual 

o  System  Decision  Paper  3 
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1.3    Operation  and  Maintenance  Phase.     "This  phase  consists  of  two 
stages . 

A.     Trnplementation  Stage. 

^^^       Purpose .     Install  the  new  system,  converting  it  frcm 
a  development  to  an  operational  status  and  conduct 
user/operation  training. 

(2)  Objectives. 

(a)  Implement  operaticnal  use  of  the  application 
system. 

(b)  Assure  that  all  ADP  operational  documentation 
and  procedures  are  adequate. 

(c)  Implement  change  control  procedures  for  the 
application  system  and  its  documentation. 

(d)  Remove  the  ADP  development  team  frcm  its 
custodial  role  with  the  aiplication. 

(3)  Activities. 

(a)  Implement  the  application  system  in  the 
operational  environment  in  accordance  with  the 
implarientation  plan. 

(b)  Verify  that  all  technical ,  computer  program, 
data  and  user  documentation  prepared  in  earlier 
stages  are  usable. 

(c)  Deliver  the  application  system  to  the 
custodianship  of  the  application  maintenance 

staff. 

(d)  Deliver  the  amplication  system  to  the 
stewardship  (ownership)  of  the  functional 
manager . 

(4)  Responsibilities. 

(a)  Applications  maintenance/operations  staff. 

(i)    Review  the  installation  process. 

fii)   Certifies  system  readv  for  installation. 

(iii)  Formally  accepts  custodianship  of  the 
system,  as  system  operators  and 
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Irnplementation  Staqe 
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maintainers. 

( b )  Project  manager . 

(i)     Ensures  that  the  system  operators  and 
maintainers  are  adequately  prepared  to 
perform  their  work  on  the  system?  and 

(ii)  Initiation  of  data  conversion;  and 

(iii)  Performing  operations  training;  and 

(iv)  Assisting  with  user  training;  and 

fv)  Installation  of  the  system;  and 

(vi)    Corrects  systems  problems  and 
documentation  as  required;  and 

(vii)   Releases  custodianship  of  the  system 
to  operations  and  maintenance  staff. 

(viii)  Ensures  that  the  functional  manager 
assumes  full  stewardship 
responsibility. 

(c)  Responsible  Functional  manager. 

(i)    Assumes  full  stewardship  (ownership) 
role  for  the  application  system. 

(ii)    Instructs  the  User  Acceptor  to  prepare 
the  Post  Implementation  Review  and 
SDP  4. 

(5)    Project  File  Documentation.   The  following 
document  will  be  added  to  the  file. 

o    Application  Stewardship  Document 
(See  Chapter  3) 
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Maintenance  Stage 
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B .   Maintenance  Stage. 

(1)  Purpose.   Keep  the  production  system  operating  in 
accordance  with  user  requirements  and  maintain 
system  efficiency. 

(2)  Objectives. 

(a)  Use  the  application  system  for  production; 

(b)  Maintain  and  make  small  modifications  to  the 
system; 

(c)  Maintain  hardware  and  software  performance; 

(d)  Monitor  system  cost  and  resource  utilization; 
and 

(e)  Provide  feedback  for  the  management  review. 

r3)    Activities.   These  standards  applv  to  both  in- 
house  and  contracted  efforts. 

(a)  Manage  the  system  operation; 

(b)  Monitor  the  system  performance; 

(c)  Perform  post  implementation  review;  and 

(d)  Maintain  and  modify  the  system  as  necessary, 
including 

(i)     Pure  maintenance.   Work  directed 

towards  making  existing  applications 
perform  as  defined  in  the 
specification  and  design  documents. 

(ii)    Conversion.   Changes  required  by  new 
hardware,  new  versions  of  system 
software,  new  compilers,  etc. 

(iii)   Modifications.   Expansions,  changes 
and  new  features  requested  by  user. 

fiv)    Optimization.   Work  done  to  make 
programs  cost  less  to  operate. 

(e)  Perform  follow-up  user  training  as  necessary. 
( 4 )    Responsibil i  t  i  e  s 
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(a)   Responsible  functional  manager.   Overall 
accountability  for  the  stewardship  of  the 
system,   including  modification  plans, 
resource  accounting,  and  the  post 
implementation  reviews. 

fh)   Systems  maintenance/operations  staff.   Act  as 
the  system's  custodians,  providing  the  staff, 
methods  and  facilities  needed  for  system 
maintenance  and  operation. 

(5)  Project  File  Documentation. 

(a)  File  maintenance.   Materials  prepared  during 
the  Maintenance  Stage  are  placed  in  the 
project  file.   T'he  Functional  Manager  is 
responsible  for  the  orderly  storage  and 
cataloging  of  its  contents. 

(b)  Documents.   The  following  documents  will  be 
added  to  the  file.   See  Chapter  3  for 
information  about  the  documents  contents. 

o  Post  Implementation  Review  Report 

o  System  Decision  Paper  4 

(6)  Other  Documentation.   The  following  documentation 
does  not  go  m  the  project  file,  but  is  maintained 
during  operation  of  the  system. 

(a)  Operation  and  maintenance  cost; 

(b)  Updates  for  the  Departmentwide  software 
inventory; 

(c)  Hardware  performance; 

(d)  System  software  performance; 
fe)   Change  control  procedures; 

(f)  Change  control  logs  (software  and  hardware 
configuration  changes) ; 

(g)  Software  version  releases; 

(h)   Scheduled  and  unscheduled  change  (work 

orders)  requirements,  including  justification 
and  cost;  and 
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(i)   Operation  manual  documentation. 
(7)    Change  Control. 

(a)  Applicability.   All  major  application  systems 
must  use  a  change  control  process.   The 
process  and  the  changes  made  by  it  must  be 
properly  documented. 

Changes  must  be  made  within  the  resources 
budgeted  for  the  operation  and  maintenance  of 
the  system.   The  operation  and  maintenance 
resources  requested  and  allocated  are  used 
only  for  the  continued  operation  of  the 
system  and  to  keep  it  running  as  designed. 
Any  major  modifications,  reconfigurations,  or 
re-developments  require  an  independent  ASLC 
project.   The  activity  must  be  conducted  in 
accordance  with  ASLC  management  standards. 

(b)  Authorization  and  acceptance.   A  procedure 
must  exist  for  approval  and  acceptance  of 
changes.   The  process  may  include  a  change 
control  board  or  an  individual  who  is 
responsible  for  ensuring  that  all  changes 
have  been  properly  evaluated.   There  should 
also  be  a  process  for  making  emergency 
changes.   These  emergency  changes,  however, 
are  reviewed  before  they  are  made  permanent. 

(c)  System  access  security.   The  application 
system  software  is  to  be  secured  from  access 
except  bv  the  individuals  assigned  the 
responsibilitv  for  control  of  the  production 
software.   These  individuals  are  responsible 
for  ensuring  that  system  and  applications 
being  installed  in  production  libraries.   The 
production  system  passwords  will  be 
restricted  to  a  verv  few,  and  changed 
periodically  and  whenever  an  employee  no 
longer  has  a  need  for  the  password.   Users, 
application  programmers,  and  anyone  not 
responsible  for  installing  the  software  are 
not  to  have  application  system  software 
access.   Development  and  testing  will  not  be 
done  with  production  programs  and  files,  and 
only  the  personnel  responsible  for 
configuration  management  will  install  system 
changes.   A  clear,  verifiable  audit  trail  of 
all  production  library  changes  must  be 
maintained. 
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(d)  Version  releases.   If  a  large  number  of 
changes  are  needed,  they  are  to  be  logically 
grouped,  analyzed,  made  in  a  change  library, 
and  then  tested  in  a  system  test 
environment.   They  are  to  be  installed  by  a 
schedule,  and  all  affected  organizations  are 
to  know  the  changes  being  made  in  advance  so 
that  comments  and  adjustments  can  be  made. 
The  logically  grouped  changes  will  be 
assigned  change  version  numbers. 

(e)  Unscheduled  changes.   When  changes  must  be 
made  for  an  emergency  or  to  meet  interface 
schedules,  the  immediacy  or  timing  of  these 
changes  may  prevent  their  being  part  of  a 
version  release.  However,  these  changes 
should  be  documented  separately  and  included 
in  the  system  test  of  the  next  version 
release  to  ensure  that  they  properly 
interface  with  the  rest  of  the  system. 
Emergency  changes  will  be  installed  in  a 
separate  physical  Library,  and  will  not  be 
moved  into  a  production  library  until  they 
have  been  system  tested  and  accepted. 

(8)    The  Post  Implementation  Review. 

(a)  General.   An  initial  review  audit  will  be 
conducted  at  a  date  agreed  upon  by  the 
functional  management  and  ADP  management 
after  the  system  is  operational.   Each  system 
will  be  reviewed  periodically  to  determine  if 
functional  requirements  are  being  met  and  if 
reports  are  valid  and  are  being  used. 

(b)  Review  objectives. 

(i)    Assure  the  application  supports  the 

policies  and  functions  that  management 
has  prescribed. 

(ii)    Review  the  controls  and  audit  trails 
needed  for  management,  auditor  and 
operational  review.   T'he  purpose  of 
these  controls  is  to  ensure  data 
integrity,  security  and  full 
functionality. 

(iii)   Evaluate  the  application's  efficiency 
and  economy  in  operation.   Re-examine 
the  cost/benefits  done  earlier  in 
light  of  this  information. 
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(iv)    Assure  the  application  conforms  with 
applicable  legal  and  regulatory 
requirements.   A  review  of  financial 
systems  must  ensure  compliance  with 
generally  accepted  accounting 
principles. 

(V)     Insure  that  documentation  is  easily 
understood  and  facilitates 
system/program  use,  maintenance  and 
auditing.   Data  documentation  is  to  be 
automated  and  kept  up-to-date. 

(vi)    Review  contingency  plans  exist  for  the 
degree  of  off-site  storage  and 
processing  required. 

(vii)  Audit  to  see  if  the  system  is  being 
operated  in  accordance  with  current 
system  procedures. 

Post  implementation  review  report.   The  post 
implementation  review  report  should  be  an 
evaluation  addressing  each  of  the  above  areas 
and  should  be  submitted  to  the  Project 
Management  Committee  with  an  information  copy 
to  the  Executive  Director  of  the  Information 
resources  Management  Council. 

(^)   Corrective  actions.   Within  20  work  days 
after  the  post  implementation  review,  the 
team  responsible  for  the  application  system 
maintenance  will  submit  to  the  Project 
Management  Committee  a  plan  that  addresses 
actions  that  will  be  taken  to  remedy  any  ADP 
related  problems  revealed  by  the  review.   It 
will  include  the  time  frames  by  which  each 
problem  will  be  corrected.   Corrective 
actions  will  be  taken  based  on  a  priority 
agreed  upon  by  the  user  and  ADP  after  the 
cost/benefit  of  the  corrections  have  been 
identified. 

^'      Application  Systems  Changes  and  Termination. 

^^'>        Application  System  Changes.   Much  of  the 
Maintenance  Stage  involves  a  repetition 

ilt^^^l^^"^^    °^  P^^°-  ^^^^  phases  and  stages.  The 
ADP  and  the  Responsible  Functional  Manager  must 
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determine  which  portions  of  the  ASLC  should  be 
repeated  in  a  particular  instance.   Guidelines  for 
ASLC  repetition  are: 

(a)  Pure  maintenance.   From  system  Construction 
and  Acquisition  Stage  through  Implementation 
Stage. 

(b)  Conversion.   From  System  Design  Stage  through 
Implementation  Stage. 

(c)  Modification.   From  Initiation  Phase  through 
Implementation  Stage. 

(d)  Optimization.   From  system  construction  and 
acquisition  through  Implementation  Stage. 

(2)   Application  System' Termination.   A  change  in 

agency  mission  can  lead  to  the  termination  of  an 
application  system's  use.  When  this  occurs  the 
Responsible  Functional  Manager  will  assure  that 
all  Project  File  information  is  cataloged  and 
stored,  so  that  it  can  be  accessed  in  the 
future.   The  ADP  Manager  responsible  for  operating 
the  application  will  assure  that  all  technical 
documentation,  orogram  source  code,  job  control 
language,  and  archived  data  files  are  retained 
pursuant  to  the  written  instructions  of  the 
Responsible  Functional  Manager.  The  technical 
information  will  be  stored  until  written 
instructions  are  received  from  the  Responsible 
Functional  Manager. 
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2.1  Project  ^eams.   All  major  application  system  projects  will 
require  two  project  teams  to  be  formed  during  the  ASLC. 
T'hese  project  teams  perform  their  work  sequentially,  not 
concurrently. 

A.  Application  Planning  Team,   'r^his  team  will  be  formed  to 
complete  the  activities  listed  as  part  of  the  Initiation 
Phase.   Team  members  will  be  from  the  functional  area 
sponsoring  the  automation  project,  since  the  work  to  be 
done  in  this  phase  focuses  upon  the  functional  area's 
business  needs.   A  member  of  the  functional  area's 
management  should  be  Project  Manager  for  the  planning 
team.   This  same  person  should  be  considered  for  the 
User  Acceptor  role  during  the  later  phases  of  the 
project. 

B.  ADP  Development  Team,   '^his  team  will  use  the  work  of 
the  application  planners,  and  complete  the  activities 
that  form  the  Development  Phase.   Someone  experienced  in 
application  system  development  management  should  be 
Project  Manager  of  this  team. 

2.2  Project  Initiation.   Activities  required  during  the  start-up 
of  either  project  team  are  the  same. 

A.  Project  Charter  Development.   A  project  charter  should 
be  developed  prior  to  the  establishment  of  an 
application  planning  team.   This  charter  serves  as  a 
written  understanding  between  the  Project  Manager  and 
the  Project  Management  Committee.   Another  charter  is 
prepared  for  the  ADP  development  project.   This  charter 
is  developed  specifically  for  each  major  application 
planning  or  ADP  development  team.   It  sets  forth  the 
scope,  objectives,  activities,  team  organization, 
responsibilities,  and  the  general  methods  of 
operation.   In  addition,  the  lines  of  authority  and 
accountability  are  clearly  identified.   The  larger  the 
project,  the  more  detailed  the  project  charter  should 
be. 

B.  Staffing  Project  Teams.   The  project  charter  defines  the 
organization  for  the  project  teams.   After  approval  of 
the  project  charter  by  the  Project  Management  Committee, 
it  will  be  necessary  to  review  the  organization  and 
determine  as  accurately  as  possible  the  specific  skills 
and  quantities  of  staff  that  will  be  needed  and 
corresponding  dates  thev  should  be  on  board  the 
project.   Project  personnel  can  include  permanent  and 
short  term  staff,  but  all  project  team  members  should 
work  full-time  on  the  project  during  their  assignment 
there.   T'he  recruitment  effort  should  center  on 
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acquiring  staff  from  within  the  agency.   Employees 
assigned  to  the  project  team  should,  at  the  minimum,  be 
ensured  of  future  placement  in  a  comparable  position  and 
grade  they  held  prior  to  their  selection.   If 
recruitment  proves  to  be  a  problem,  then  staff  may  be 
recruited  from  outside  the  agency  —  either  government 
or  industry. 

Project  Manager.   System  development  work,  whether  it  is 
major  new  system  work  or  a  small  maintenance  job,  is 
project  oriented;  i.e.,  it  has  a  definitive  start  or 
initiation  point  and  a  goal  which,  when  reached, 
terminates  the  system  development  activity.   A 
particularly  useful  way  of  approaching  such  work  is  to 
appoint  a  project  manager.   For  large  projects,  the 
Project  Manager  is  usually  assigned  responsibility  for 
only  the  one  project.   The  Project  Manager  is 
responsible  for  coordinating  the  efforts  of  the  many 
organizational  units  and  functions.   The  manager  of  the 
ADP  project  team  should  have  ADP  project  management 
experience.   Responsibilities  include: 

(1)  Coordinate  all  management  and  technical  aspects  of 
the  AS  throughout  its  phases. 

(2)  Determine  the  project  team  organization  based  on 
user  and  ADP  recommendations. 

(3)  Provide  detailed  work  assignments,  ensuring  that 
written  tasks  exist  for  all  work,  and  that 
measurement  criteria  exist  that  define  what 
constitutes  acceptable  performance  with  respect  to 
each  task.   Ideally,  performance  standards  should 
be  developed  for  each  team  member. 

(4)  Performance  of  system  planning  design  and 
implementation. 

f5)  Ensure  conformance  with  user  requirements  in  the 
definition,  design,  acquisition  and  construction 
stages  of  the  AS  development. 

Schedule  and  direct  formal  milestone  reviews. 

Resolve  problems  related  to  all  stages. 

Oversee  preparation  of  AS  test  plans  and  test 
reports. 

Manage  system  tests. 

Provide  documents  that  must  be  produced  to 


(6) 

(7) 

(8) 

(9) 

(10) 
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document  the -AS  project,  and  keep  them  in  the 
project  file. 

(11)   Meet  ASLC  and  project  standards  outlined  in  this 
handbook. 

°-   P'^oject  Management  Committee  (PMC)  .   The  concept  of  a 
Project  Management  Committee  stems  from  the  need  to 
secure  executive  management  involvement,  representing 
S?rL^-^  "^^5  ^""^  information  systems  organizations,  in 
directing  and  controlling  the  evolution  of  an 
organization's  application  systems.   The  Project 
Management  Committee  acts  as  a  "Board  of  Directors"  for 
^h!  ;^P\^^^t^°"  system  and  is  responsible  for  overseeing 
the  development  of  the  life  cycle  strategy  plans, 
recommending  resource  levels  based  on  those  plans,  and 
reviewing,  monitoring  and  prioritizing  activities  for 
the  project.   The  Project  Management  Committee  will 
conduct  milestone  reviews  of  the  project.   The  Project 
Management  Committee  may  choose  to  exercise  more 
rigorous  control  of  the  largest,  most  critical 
projects.   The  committee  will  be  formed  when  the 
application  planning  team  is  formed,  and  will  continue 
to  have  executive  responsibility  until  the  post- 
implementation  review  is  completed.   The  PMC  is 
responsible  for  initiating  agreements  between 
participants  when  a  multi-organization  application  is 

hS  Sf.r''l^fu''^^'°"*   budgeting  and  cost  chargeback  will 
oe  part  of  these  agreements. 

F,.      User  Acceptor.   A  key  measure  of  success  for  an 

application  system  is  the  degree  of  user  acceptance  and 
satisfaction  with  the  system.   The  critical  factor  in 
achieving  a  high  level  of  acceptance  and  satisfaction  is 
^f!^un"^^?^^^"^®"^  ^^  ^^^  system  development  process.   The 
establishment  of  a  User  Acceptor  is  an  organizational 
strategy  for  obtaining  user  participation.   A  User 
Acceptor  is  an  individual  appointed  at  the  time  a  system 
development  effort  is  initiated.   The  individual  is  to 

!?,=  i   /   .''°°''^'"^^^'  ^^^"^  t^^  "=^^  perspective,  those 
system  development  projects  in  a  user  area.   The  User 
Acceptor  interacts  with  the  Project  Manager  in  a 

customer-contractor"  relationship  during  the  ADP 
proiiect  team's  tenure.   Specific  responsibilities  of  the 
User  Acceptor  include  the  following: 

(1)  Participate  in  Mission  Analysis  Stage  as  a  team 
member,  and  perhaps  as  the  Project  Manager  during 
the  Initiation  Phase; 

(2)  Coordinate  with  the  Project  Manager  all 
requirements  for  support  from  the  user  area; 
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(3)  Monitor  the  progress  of  the  project  in  terms  of 
cost,  schedule,  and  quality;  and 

(4)  Review  and  recommend  approval  of  each  phase  of  the 
project  as  it  is  completed. 

ASLC  Project  Monitor.   The  ADP  organization  should  have 
an  organizational  unit  to  control  all  requests  for 
services  and  monitor  projects.   This  unit  provides 
project  management  and  ASLC  assistance  to  project 
managers. 

^'      Project  Scheduling.   The  establishment  of  an  accurate 
schedule  is  essential  to  the  successful  conclusion  of 
anyproject.   Scheduling  should  be  based  on  the  ASLC 
activities  and  incorporated  into  project  work  plan. 
Initially,  the  schedule  is  one  of  the  more  important 
tools  used  to  cost  the  project.   During  the  life  of  the 
project,  the  schedule  will  be  used  as  a  basis  for 
measuring  progress. 

(1)  Schedules  developed  during  a  project  are  important 
to  the  management  of  the  project.   'T'he  budget, 
used  to  determine  allocations  of  funds,  is  largely 
d'erived  from  the  schedule..  Resource  allocation 
also  uses  the  schedule  as  important  input.   The 
schedule  established  in  the  work  plan  is  the 
primary  measuring  stick  in  doing  progress 
reporting.   Clearly  the  most  accurate  possible 
schedule  is  important  to  the  successful  completion 
of  the  project. 

(2)  Bottom-up  project  scheduling  approaches  break  a 
project  into  its  component  tasks,  determine  the 
time  requirements  for  each  and  sum  the  components 
to  determine  an  estimated  completion  date  for  the 
project.   As  it  is  generally  easier  to  make  more 
accurate  estimates  of  smaller  work  units,  the 
bottom-up  approaches  are  generally  more  accurate 
than  the  top-down.   The  most  common  bottom-up 
approaches  are: 

(a)  Gantt  charts,   fhis  method  is  good  for 
illustrating  which  job  steps  may  be  performed 
simultaneously. 

(b)  PERT  charts.   PERT  is  good  for  illustrating 
the  relationship  between  tasks.   It  also 
shows  which  sequence  of  tasks  will  take  the 
longest  and  therefore  is  the  constraining 
factor  on  project  completion. 
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(c)      Critical  path  method.   CPM  is  similar  to  PERt^ 
except  that  in  a  CPM  diagram  the  tasks  are 
boxes  instead  of  lines. 

{<3)   Automated  methods.   Various  software  packages 
exist  to  assist  in  scheduling  very  large 
projects.   Most  use  some  variation  of  PERT'  or 
CPM.   This  is  strongly  recommended  for  major 
application  projects. 

H.   Estimating  Staff  Requirements.   Estimating  project  human 
resource  requirements  is  a  four  step  process  as 
discussed  here. 


fl)    Understanding  the  Scope  of  the  System.   A 

comprehensive  understanding  of  the  scope  of  the 
system  minimizes  the  likelihood  of  forgetting 
tasks  or  misunderstanding  the  complexity  of  the 
system.   In  general,  the  estimator  should  be  an 
individual  close  to  the  source  of  the  work.   This 
means  that  the  individuals  responsible  for  each 
task  to  be  .performed  should  develop  their  own 
estimates  and  provide  these  estimates  to  the 
project  manager.   in  this  way  they  will  feel  a 
greater  sense  of  responsibility  for  holding  close 
to  their  estimates  during  execution. 

(2)  Project  ^-asking.   Identifying  the  tasks  to  be 
performed  by  the  team  should  be  accomplished  prior 
to  attempting  to  estimate.   Depending  on  the  stage 
in  the  development  process  for  which  the  estimate 
is  being  prepared,  the  identification  of  tasks  may 
be  accomplished  by  extraction  and  refinement  of 
larger  units  of  work.   A  definitive  list  of  tasks 
to  be  estimated  is  a  prerequisite  to  estimating 
the  cost  of  a  stage.   Any  precedential 
relationships  among  the  tasks  should  be  well 
understood  before  beginning.   Tasking  for  a  stage 
will  be  done  during  the  preceding  stage  to  assure 
valid  cost  figures  are  used  in  SDP's. 

Use  of  an  automated  project  scheduling  system  will 
help  determine  the  impact  of  a  change  to  one  task 
upon  the  entire  project's  resources. 

(3)  Estimate  Tjme  Required.   Once  the  tasks  for  a 
stage  have  been  identified  and  documented,  the 
amount  of  time  for  each  task  will  be  estimated. 
This  job  should  be  done  on  a  task  by  task  basis, 
keeping  in  mind  the  quantity  and  experience  levels 
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.  of  the  staff  assigned  to  a  task. 

(4)    Review  Estimates.   Automated  project  schedulinq 
systems  will  facilitate  production  of  initial  ' 
project  staffing  reports,  and  allow  a  regular 
review  of  the  intitial  staffing  orojections 
throughout  the  life  cycle.   Accurate  estimates  are 
most  likely  when  the  estimated  time  required  to 
complete  a  specific  task  is  reviewed  with  the 
person/s  actually  doing  the  work.   As  the  project 
advances  through  the  life  cycle,  this  method  of 
time  estimate  reviews  is  likely  to  result  in 
increasingly  accurate  estimates.   These  reviews 
should  be  scheduled  by  the  Project  Manager  as 
tasks  are  produced. 

2 .  3  Project  Reporting  Requirements. 

Both  types  of  project  teams,  planning  and  ADP  development, 
will  provide  reports  to  designated  authorities  at  each  of 
the  project  milestones,   'nhe  Project  Manager  will  keep  a 
copy  of  all  milestone  reports  and  the  decisions  of 
responsible  authorities,  and  assure  they  are  available 
throughout  the  system  life  cycle. 

^-   Milestone  0  Reporting.   Milestone  0  occurs  after  Mission 
Analysis  Stage  and  prior  to  Concept  Development  Stage 
during  Initiation  Phase.   The  Application  Planning  Team 
IS  responsible  for  meeting  these  reporting  requirements. 

(1)    Mission  Need  Statement  (MNS)  Preparation. 

fa)   Purpose.   Describe  a  mission  need,  justify 

the  exploration  of  alternative  solutions  and 
identify  estimated  costs  associated  with  this 
action  to  the  decision-makers, 

(b)   Discussion. 

(i)    The  MNS  is  the  reporting  document  upon 
which  the  Milestone  0  decision  is 
based.   it  identifies  and  defines: 

o   A  specific  need  within  a  mission 
area. 

o   The  relative  priority  of  the  need 
within  the  mission  area. 

o   The  factor (s)  causing  the  need. 

o   The  date  when  the  need  must  be 
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addressed  or  new  capability  must 
be  implemented. 

o   The  general  magnitude  of  resources 
which  the  functional  sponsor  is 
required  to  invest  to  fill  the 
need. 

o   The  effect  upon  mission 

performance  if  no  action  is  taken. 

(ii)    A  MNS  is  required  for  each  projected 
major  application  system  (AS) . 

fiii)   The  need  identified  in  a  MNS  is 

defined  as  narrowly  as  possible  using 
terms  used  in  the  functional  areas 
with  the  need,  though  the  scope  of  the 
need  identified  in  the  MNS  is  narrowly 
defined,  solutions  to  the  problem  are 
not  specified.   Alternative  concepts 
and  associated  risks  are  evaluated 
during  the  Concept  Development  Phase 
prior  to  Milestone  1. 

(c)   Procedures. 

(i)    Preparer.   The  MNS  should  be  prepared 
by  the  Application  Planning  Team's 
project  manager.   The  MNS  should  be 
written  in  functional  terms,  without 
any  attempt  use  ADP  terms  or  to 
specify  ADP  solutions. 

(ii)    Length.   The  MNS  should  not  exceed  six 
pages  in  length. 

(iii)   Approval.   The  MNS  is  approved  by  the 
Proiect  Management  Committee.   The 
Project  Management  Committee  will 
validate  the  need  and  certify  the 
intent  to  provide  program  funding 
prior  to  each  milestone  decision.   The 
Project  Manager  will  coordinate  review 
of  the  MNS  by  the  IRMRC. 

(iv)    Duplication,  '^he   User  Acceptor, 

responsible  functional  manager  and  the 
Project  Management  Committee  should 
review  the  MNS  to  determine  if  other 
similar  AS ' s  are  in  existence  which 
could  satisfy  the  user's 
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requirements.  A  copy  of  each  approved 
MNS  will  be  forwarded  to  the  IRMRC  for 
their  review. 

(V)    Priority.   The  responsible  functional 
manager  should  specify  the  relative 
priority  of  this  project  to  other 
approved  projects  under  his 
sponsorship  within  the  mission  area  in 
the  MNS  approval  document. 

(2)    Appendices.   Extract  the  following  documents  from 
your  Project  File  and  attach  them  as  appendices: 

(a)  Cost/Benefit  Analysis. 

(b)  Mission  Process  Model. 

(c)  Information  Model. 

(d)  Organization  Model. 

B.   Milestone  1  Reporting.   The  Application  Planning  'I'eam  is 
responsible  for  meeting  these  reporting  requirements. 
Milestone  1  occurs  after  Concept  Development  Phase  and 
prior  to  System  Analysis  Stage. 

(1)  Reporting  Process.   A  system  decision  paper  (SDP) 
will  be  prepared  and  reviewed  with  the  responsible 
functional  manager.   Address  the  continued 
validity  of  the  MNS  which  was  the  basis  for 
initiating  the  project,  in  the  "Overview" 
paragraph  of  the  SDP.   If  the  MNS  has  changed 
since  the  previous  milestone,  attach  a  copy  of  the 
revised  MNS.  Along  with  the  revised  MNS,  describe 
any  changes  to  the  previously  approved  MNS,  and 
reasons  for  change.   All  changes  will  be  approved 
by  the  Project  Management  Committee  along  with  the 
recertif ication  of  intent  to  program  funds  and 
revalidation  of  the  mission  need.   Do  not  expand 
the  level  of  detail  approved  in  the  MNS  unless 
specifically  directed  to  do  so. 

(2)  System  Decision  Paper  1  (SDPl)  Preparation. 

(a)  Purpose.   Concisely  present  primary  project 
issues  and  recommendations  to  the  responsible 
authorities  and  obtain  authoritv  to  begin 
developing  an  ADP  system. 

(b)  Discussion.   SDPl  is  a  management  summary  of 
the  pro^iect,  as  well  as  a  decision  paper  for 
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Milestone  1  decisions.   It  references  each  of 
the  detailed  documents  prepared  and  clearly 
defines  management  issues  and  recommends 
solutions.   Conflicting  viewpoints  are 
summarized  and  documented.   Documentation  of 
management  decisions  occurring  during  the 
course  of  the  project  life  should  be  kept 
with  SDPl  in  the  project  file. 

(c)  Procedures.  SDPl  is  prepared,  coordinated, 
and  submitted  by  the  Project  Manager  to  the 
Project  Management  Committee  for  review  and 
approval. 

(i)     Early  coordination.   The  Project 
Manaaer  is  strongly  encouraged  to 
communicate  regularly  with  the  Project 
Management  Committee  early  so  that 
questions  and/or  concerns  can  be 
resolved  prior  to  the  formal  review. 
The  Project  Charter  will  clearly 
describe  the  relationship  between  the 
Project  Manager  and  the  PMC. 

(ii)    Briefing,   fhe  Project  Manager  should 
brief  the  Project  Management  Committee 
regarding  SDPl  at  this  milestone.   The 
committee  will  vote  for  or  against  ADP 
development  of  the  proposed 
application  system. 

(iii)   Length 

o   Milestone  1  -  SDPl  should  not 
exceed  12  pages  in  length, 
excluding  appendices. 

(3)    Appendices.   Extract  the  following  documents  from 
your  project  file  to  be  submitted  as  appendices  to 
SDP  1. 

(a)  System  architecture. 

(b)  Cost/benefit  analysis. 

(c)  Life  cycle  strategy. 

(<3)   Data  communications  architecture. 

(e)  Data  architecture. 

(f)  Pevised  MNS . 
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C.   Milestone  2  Reporting.   Milestone  2  occurs  after  the 
System  Design  vStage  and  before  the  System  Construction 
and  Acquisition  Stage.   The  ADP  project  team  is 
responsible  for  meeting  these  reporting  requirements. 

(1)  Reporting  Process.   SDP2  will  be  prepared  and 
reviewed  with  the  Project  Management  Committee. 
The  continued  validity  of  the  MNS  which  was  the 
basis  for  initiating  the  project  will  be  addressed 
in  the  "Overview"  paragraph  of  SDP2.   If  the  MNS 
has  changed  since  the  previous  milestone,  attach  a 
copy  of  the  revised  MNS.   Also,  describe  any 
chanaes  to  the  previously  approved  MNS,  and  the 
reasons  for  change.   All  changes  will  be  approved 
by  Project  Management  Committee,  along  with  the 
recertif ication  of  intent  to  program  funds  and 
revalidation  of  the  mission  need.   Do  not  expand 
the  level  of  detail  approved  in  the  MNS  unless 
specifically  directed  to  do  so.   If  changes  in  the 
project  scope  are  significant,  re-entering  the 
life  cycle  process  beginning  with  the  mission 
analysis/project  initiation  must  be  considered. 

(2)  System  Decision  Paper  2  (SDP2)  Preparation. 

(^)   Purpose.   Concisely  present  primary  project 
issues  and  recommendations  to  the  Project 
Management  Committee,  so  that  they  can  decide 
whether  to  proceed  with  the  system's 
construction. 

(b)  Procedures.  SDP2  is  prepared,  coordinated, 
and  submitted  by  the  Project  Manager  to  the 
Project  Management  Committee  for  review  and 
approval. 

fi)    Early  coordination.   The  Project 
Manager  is  strongly  encouraged  to 
start  communicating  with  the  committee 
early  so  that  questions  and/or 
concerns  can  be  resolved  prior  to  the 
formal  review. 

(ii)    Updating.   When  updating  prior  SDPs, 
if  changes  have  not  occurred  under 
certain  entries,  submit  the  prior  SDP 
and  mark  "no  change  as  of      . " 


(iii)   Briefing.   Brief  the  committee  on  the 
recommendations  in  SDP2.   Thev  will 
vote  to  approve  or  deny  construction 
of  the  application  system. 
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(iv)    Length 

o   Milestone  2  -  '^he  SDP  should  not 
exceed  20  pages  in  length, 
excluding  appendices. 

(3)    Appendices.   The  following  should  be  extracted 
from  your  project  file,  and  included  in  the 
appendices  of  SDP  2. 

(a)  Cost/benefit  analysis  (Revision) , 

(b)  Data  communications  requirements. 

(c)  Data  processing  equipment  requirements. 

(d)  Revised  life  cycle  strategy. 

D.   Milestone  3  Reporting.   Milestone  3  occurs  after  the 
Development  Phase  and  prior  to  placing  the  AS  in 
operation.   T'he  ADP  project  team  is  responsible  for 
meeting  these  reporting  requirements. 


(1) 


(2) 


Reporting  Process.   A  system  decision  paper  will 
be  prepared  and  reviewed  with  the  Project 
Management  Committee.  The  MNS  should  be  reviewed 
to  assure  its  continued  validity,  and  the  results 
of  this  review  recorded  in  the  "Overview"  section 
of  the  SDP.   T'he  committee  will  decide  whether  or 
not  to  proceed  with  system  implementation. 

System  Decision  Paper  3  Preparation. 

(a)   Purpose.   Present  primary  project  issues  and 
recommendations  to  the  Project  Management 
Committee,  so  that  they  can  decide  whether  or 
not  to  proceed  with  system  implementation. 

fb)  Procedures.  SDP3  is  prepared,  coordinated, 
and  submitted  by  the  Project  Manager  to  the 
Project  Management  Committee  for  review  and 
approval . 

(i)     Early  Coordination.   The  Project 
Manager  is  strongly  encouraged  to 
start  communicating  with  the  committee 
early  so  that  questions  and/or 
concerns  can  be  resolved  prior  to  the 
formal  review. 

(ii)    Updating.   When  updating  SDPs,  if 
chanaes  have  not  occurred  under 
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certain  entries,  submit  the  prior  SDP 
and  mark  "no  change  as  of  .  " 

(iii)   Briefing,   fhe  Project  Manager  will 

brief  the  committee,  so  they  can  make 
an  informed  decision  regarding  system 
implementation. 

(iv)    Length. 

o   Milestone  3  -  SDP  3  should  not 
exceed  20  pages  in  length, 
excluding  appendices. 

(3)    Appendices.   Extract  the  following  documents  from 
the  project  file,  and  submit  as  appendices  to 
SDP  3: 

(a)  Cost/benefit  analysis  (Revised). 

(b)  Revised  life  cycle  plan. 

(c)  Implementation  plan. 

(d)  Conversion  plan. 

(e)  User  ^raining  plan. 

(f )  Post  implementation  review  plan. 

fg)  System  acceptance  report. 

Milestone  4  Reporting.   Milestone  4  occurs  after  the  AS 
has  been  put  in  operation.   The  User  Acceptor  and  the 
functional  manager  are  responsible  for  meeting  these 
reporting  requirements. 

(1)  Reporting  Process.   A  system  decision  paper  will 
be  prepared  and  reviewed  with  the  Project 
Management  Committee.   A  post-implementation 
review  will  be  conducted,  and  the  results  reported 
at  the  same  time. 

(2)  System  Decision  Paper  4  Preparation. 

fa)   Purpose.   Present  primary  project  issues  and 
recommendations  to  the  Project  Management 
Committee,  so  that  the  effectiveness  of  the 
operational  system  can  be  reviewed. 
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(b)   Procedures.   SDP4  is  prepared,  coordinated, 
and  submitted  by  the  User  Acceptor  to  the 
Project  Management  Committee  for  review  and 
approval. 

fi)    Early  coordination.   The  User  Acceptor 
is  strongly  encouraged  to  start 
communicating  with  the  committee  early 
so  that  questions  and/or  concerns  can 
be  resolved  prior  to  the  formal  review 
cycle. 

fii)    Updating.   When  updating  prior  ADPs, 
if  changes  have  not  occurred  under 
certain  entries,  submit  the  prior  RDP 
and  mark  "no  change  as  of  _____." 

(iii)   Briefing.   The  User  Acceptor  will 

brief  the  committee  on  the  results  of 
the  Post  Implementation  Review. 

fiv)    Length. 

o   Milestone  4  -  SDP  4  should  not 
exceed  20  pages  in  length, 
excluding  appendices. 

(3)    Appendices.   Extract  the  following  document  from 
the  project  file,  and  submit  as  an  appendix  to 
SDP  4: 

(3)   Application  stewardship  document. 

(a)   Post  implementation  review  report. 

2. 4  Management  Oversight  of  Projects. 

Management  oversight  and  control  of  both  types  of  project 
teams  is  an  important  contributor  to  the  successful 
management  of  application  system  development.   There  are  two 
bodies  that  directly  review  and  exercise  management  control 
of  the  application  development  and  acquisition  process. 

A.  Project  Management  Committee.   The  PMC  will  review  the 
reports  of  the  Project  Manager  at  each  milestone  and 
make  a  go/no  go  decision  with  regard  to  the  next  stage 
of  the  life  cycle.   See  Section  2.5  of  this  chapter  for 
a  milestone  review  checklist  to  be  used  by  the  PMC.   See 
Section  2.2.D  of  this  chapter  for  more  information  about 
the  PMC. 

B.  IRMRC.   This  departmental  executive  committee  has  been 
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convened  by  the  Under  Secretary.   Composed  of  the  Under 
Secretary  and  representatives  of  the  Bureaus,  this  group 
reviews  the  progress  of  major  application  system 
projects. 

As  soon  as  a  determination  is  made  that  a  major 
application  system  is  to  be  considered,  the  IRMRC 
Executive  Director  (Director,  PIR)  will  be  advised  in 
writing  by  the  responsible  functional  manager.   The 
Executive  Director  will  inform  the  functional  manager  of 
the  reporting  requirements  of  the  IRMRC. 

2.5  Milestone  Review  Checklist.   The  checklist  is  a  list  of 

criteria  to  be  applied  by  the  Project  Management  Committee 
at  each  milestone.   It  is  intended  as  a  guide  to  help 
Project  Managers  and  others  prepare  for  milestone  review 
activities.   The  checklist  is  not  all  inclusive;  it  lists 
typical  criteria  that  have  iDeen  applied  in  the  past  and  that 
are  relevant  to  a  broad  range  of  application  systems.   All 
of  the  criteria  may  not  be  applicable  to  every  application 
system. 

A.  Milestone  0. 

(1)  The  need  described  in  the  MNS  is  a  valid  concern, 
mission  related,  and  worth  solving. 

(2)  The  MNS  describes  a  mission  need  in  mission  terms, 
not  a  set  of  hardware  and  software. 

(3)  Existing  constraints  that  affect  the  ability  of 
the  agency  to  meet  the  mission  need  have  been 
clearly  identified  and  described. 

(4)  The  resources  required  for  Concept  Development 
Stage  are  reasonable. 

(5)  The  schedule  proposed  is  achievable. 

(6)  A  proven  mission  analysis  methodology  is  being 
used. 

B.  Milestone  1. 

(1)  The  mission  need  is  reaffirmed  to  be  essential. 

(2)  A  Project  Manager  has  been  appointed  and 
chartered,  and  necessary  staffing  approved. 

(3)  The  alternative  design  concepts  adequately  address 
solving  the  mission  deficiency  or  problem. 
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(4)  The  functional  objectives  have  been  prioritized. 

(5)  The  general  mission  functional  requirements, 
including  security  requirements,  have  been 
developed  and  validated. 

(6)  'T'he  reasonable  alternatives  were  considered. 

(7)  The  projected  resource  investment  for  the  selected 
alternatives  has  been  estimated  and  is  consistent 
with  the  stated  constraints. 

(8)  Use  of  available  and  existing  automated  systems 
has  been  adequately  considered. 

(9)  System  consolidation  considerations  have  been 
adequately  treated  in  the  planning. 

(10)  Standardization  and  interoperability  requirements 
have  been  adequately  considered. 

(11)  Risks  and  problem  areas  have  been  identified  and 
adequately  treated  in  the  planning. 

(12)  Strategies  to  facilitate  the  transition  from  the 
current  functional  system,  whether  automated  or 
not,  to  any  of  the  alternative  systems  to  be 
explored  have  been  described. 

(13)  A  life  cycle  strategy  has  been  completed. 

(14)  Areas  involving  new  technology,  unstable 
requirements,  and  fund  availability  have  been 
identified  and  assessed. 

(15)  A  cost/benefit  analvsis  has  been  prepared. 

(16)  Svstem,  data  and  data  communications  architectures 
have  been  prepared. 

Milestone  2. 

(1)  The  mission  need  is  reaffirmed. 

(2)  '^he  functional  svstem  design  has  been  validated 
and  the  baseline  for  the  functional  system  has 
been  established. 

(3)  The  data  base  design  has  been  validated  and 
documented  in  a  data  dictionarv/directorv  svstem. 

(4)  Specifications  for  hardware,  software,  firmware. 
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and  data  base  have  been  developed. 

f5)    Plans  for  logistics  support,  security  protection, 
training,  operational  test  and  evaluation, 
configuration  management,  organizational 
relationships,  development,  acquisition,  and 
maintenance  support  have  been  updated  (this  is  the 
remainder  of  the  life  cycle  management  strategy). 

(6)  Risk  analysis  to  reflect  that  total  system 
development  has  been  reassessed. 

(7)  The  cost/benefit  analysis  has  been  updated. 

(8)  Acquisition  plans  to  obtain  the  required  ADPE  and 
other  resources  are  finalized. 

(9)  Planned  computer  resources  will  meet  stated 
operational  needs. 

(10)  Future  changes  to  hardware,  software,  firmware  and 
data  bases  can  be  accommodated  without  system 
redesign. 

(11)  Interface  and  interoperability  reauirements  can  be 
met. 

(12)  Trade-off  between  hardware,  software,  firmware  and 
manual  procedures  have  been  made. 

(13)  If  parallel  development  efforts  will  be  used, 
control  mechanisms  are  established. 

(14)  Contractor  versus  Government  develooment  issues 
have  been  resolved. 

(15)  Planning  for  preparation  of  test  and  evaluation 
plan  is  adequate. 

(16)  Test  data  are  representative  of  the  total  range  of 
data  and  conditions  that  the  system  might 
encounter. 

(17)  Test  data  meet  appropriate  pass/fail  criteria 
relevant  to  regulatory  constraints. 

(18)  Testing  will  clearly  identify  whether  deficiencies 
are  software  or  hardware  related. 

(19)  Preliminary  plans  adequately  describe  a  concept 
for  training,  logistical  support,  organizational 
relationships,  post- implementation  support  and 


70 


Project  Management,  Reporting  and   Control 

Chapter  2 


operation  of  an  automated  system. 

(20)  The  acquisition  strategy  effectively  integrates 
the  technical,  business  and  management  elements  of 
the  project  and  supports  the  achievement  of 
project  goals  and  objectives. 

(21)  Interfaces  with  other  systems  have  been  adequately 
identified  and  defined. 

Milestone  3. 

(1)  T'he  mission  need  is  reaffirmed. 

(2)  Computer  programs  and  data  bases  have  been  fully 
developed,  documented  and  tested. 

fS)    Standardization  and  interoperability  requirements 
have  been  satisfied. 

(4)  System  support  documentation  has  been  developed. 
T'his  includes  maintenance  manuals,  user  manuals, 
and  operation  manuals.   Automated  computer  system 
documentation  can  be  substituted  for  maintenance 
and  operation  manuals. 

(5)  Unit  and  system (s)  level  test  and  evaluation 
results  support  a  decision  to  proceed  with 
application  system  installation. 

(6)  Change  control  procedures  for  use  after 
implementation  are  complete,  and  include  updates 
of  computer  program  and  data  documentation. 

(7)  The  User  Acceptor  has  confirmed  that  the  developed 
system  satisfies  the  design  and  functional 
requirements. 

(8)  Life  cycle  schedule,  cost  and  budget  estimates  are 
realistic  and  acceptable. 

The  cost  benefit  analysis  has  been  updated. 

The  system  is  cost  effective  and  affordable  and 
remains  the  best  acceptable  solution. 

Trade-offs  have  been  made  to  balance  cost, 
schedule  and  performance  effectively. 

The  acquisition  strategy  has  been  updated  and  is 
being  executed. 

'T'he  end  products  of  development  are  controlled  as 


(9) 

(10) 

(11) 

(12) 

(13) 
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configured  items. 

(14)  Mission  planning  and  budgeting  supports  the 
acquisition  strategy  and  provides  flexibility  for 
delivery  dates  and  quantities  when  options  are 
used . 

(15)  Issues  concerning  delivery,  quality  assurance  and 
facilities  are  identified  and  satisfactorily 
resolved. 

(16)  The  project  management  structure  and  plan  are 
sound  and  adequately  supported. 

(17)  Planning  for  implementation  is  adequate  including 
manpower  and  training,  documentation,  logistics 
readiness,  operational  considerations,  security, 
and  integration  with  existing  operational  systems. 

(18)  System  deficiencies  revealed  in  testing  have  been 
satisfactorily  resolved.   Deficiencies  not 
resolved  have  been  scheduled  for  a  later  version 
or  release  of  the  system. 

(19)  Maintenance  support  facilities  are  ready  for 
operation. 

(20)  Plans  for  anticipated  system  improvements  have 
been  established. 

(21)  ADPE  acquisition  is  on  schedule. 
E.   Milestone  4. 

(1)  The  mission  need  is  reaffirmed. 

(2)  All  changes  to  the  system  are  accounted  for  in  the 
change  control  system,  and  computer  program  and 
data  documentation  are  being  kept  up-to-date. 

(3)  System  operates  effectively  and  efficiently,  in 
ail  respects. 

(4)  'T'he  Cost/Benefit  Analysis  is  updated. 

(5)  System  is  essential  to  the  function  supported. 

(6)  The  system's  operation  is  adequately  funded. 

(7)  System  security  measures  are  effective. 
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(81    Training,  logistic  support,  organizational 

relationships,  post-implementation  support  and 
operations  are  adequate  for  the  system. 

(9)  ADPE  is  not  saturated,  or  plans  for  eliminating 
saturations  have  been  developed. 

(10)  T'he  Application  Stewardship  Document  has  been 
signed  by  the  responsible  functional  manager, 
relieving  the  project  manager  of  stewardship  of 
the  application  system. 

(11)  Change  control  processes  are  being  used  and  result 
in  an  auditable  audit  trail  for  all  application 
system  changes. 
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3.0   Overview.   This  chapter  contains  details  of  documents 
required  during  the  life  cycle  of  a  major  application 
system.   While  the  substance  of  all  the  documents  described 
in  this  chapter  needs  to  be  covered  by  each  application 
development  project,  many  of  the  documents  can  be  combined 
with  other  documents  at  the  project  manager's  discretion. 
These  documents  are  marked  with  an  asterisk  (*)  below. 
Documents  without  an  asterisk  beside  them  should  be  produced 
with  the  prescribed  title  and  information. 

A.  Initiation  Phase  Documents. 

Project  Request 
Mission  Analysis  Methodology 
Cost/Benefit  Analysis 
Project  Charter 
Organization  Model 
Mission  Process  Model 
Information  Model 
Mission  Need  Statement 

*  System  Objectives 

*  Application  System  Architecture 

*  Data  Architecture 

*  Data  Communications  Architecture 
System  Life  Cycle  Strategy 
System  Milestone  Dates 

System  Life  Cycle  Resources  Estimates 
Revised  Cost/Benefit  Analysis 
Revised  Mission  Need  Statement 
System  Decision  Paper  1 

B.  Development  Phase  Documents 

*  Current  System  Description 

*  Detailed  Functional  Requirements 

*  Data  Requirements 
Design  Proposal 

Detailed  Cost/Benefits  Analysis 
Revised  Life  Cycle  Strategy 
System  Decision  Paper  2 

*  ADPE  Specifications 

*  Application  Software  Documentation 
System  Test  Plan 

System  Acceptance  Report 
Implementation  Plan 

*  Conversion  Plan 

*  User  Training  Plan 

Post  Implementation  Review  Plan 

*  Data  Processing  Manual 

*  User  Manual 

Control,  Backup  and  Security  Summary 

*  Operations  Manual 
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System  Decision  Paper  3 

C.    Operation  and  Maintenance  Phase  Documents. 

Application  Stewardship  Document 
Post  Implementation  Review  Report 
System  Decision  Paper  4 
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3  . 1   Initiation  Phase  Documents. 

A.    Initiation  Stage  Documents. 

(1)    Project  Request.   This  document  is  prepared  by 
the  functional  manager  who  is  initiating  the 
request  for  an  automated  system.   The  document 
will  be  no  more  than  5  pages  in  length. 

(a)  Requestor's  name  and  position 

(b)  Need  statement 

(c)  Need  impact  or  cost 

(d)  Mission fs)  impacted 

(e)  Organizational  units  impacted 

(f)  Location,  identity  and  size  of  the 
organizations  Impacted 

(g)  Description  of  the  work  to  be  automated. 

f 2 )    Mission  Analysis  Methodology  pescription.   This 
document,  designed  by  the  Project  Manager, 
describes  the  mission  analysis  methodology  used 
to  produce  the  required  initiation  phase 
information. 

(3)    Cost/Benefit  Analysis.   The  initial  cost/benefit 
analysis  is  a  valuable  tool  when  deciding  whether 
the  costs  of  Concept  Development  Stage  are 
justified.   Since  it  is  limited  to  quantif iables, 
it  should  not  be  over-emDhasized  in  developing  a 
recommendation  at  this  stage. 

(a)    Costs.   (New  versus  current  system) 

(i)      Non-recurring  costs.   Include  non- 
recurring  costs  (capital  and 
other),  such  as  studies,  personnel 
training,  site  modifications, 
supplies  and  security 
procedures.   Total  the  non- 
recurring costs  for  each  system. 

(ii)      Recurring  costs.   Include 

recurring  costs  such  as  rental, 
maintenance,  utilities,  data 
communications  and  personnel. 
Total  the  recurring  costs  for  each 
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system. 

(iii)    Total  annual  cost.   Total  the  non- 
recurring  and  recurring  cost 
subtotals  for  each  system. 

(iv)     System  life  cost.   Calculate  the 

total  cost  over  the  system  life  by 
summing  the  total  costs  for  all 
years  of  the  system  life  for  both 
the  existing  and  new  systems. 

(b)  Benefits.   Show  the  benefits  of  the  new 
system  over  the  existing  system. 

(i)      Annual  tangible  benefits.   Enter 
the  quantifiable  benefits  for  the 
year  of  the  life  cycle  in  which 
the  benefits  are  realized. 

(ii)     System  life  benefit.   Calculate 

the  total  benefit  for  all  years  of 
the  life  cycle. 

(c)  Payback  period.   Calculate  the  year  and 
month  in  which  the  sum  fin  current  dollars) 
of  benefits  first  exceeds  the  sum  of  the 
costs. 

(d)  Intangible  benefits.   Intangible  benefits 
must  be  evaluated  to  decide  whether  the 
proposed  system  should  be  developed.   List 
and  discuss  each  intangible  benefit, 
including  meeting  legal  and  regulatory 
requirements. 

(4)  Project  Charter.   Designed  and  prepared  by  the 
responsible  functional  manager. 

(5)  Organization  Model.   This  product  documents  the 
organizational  units  impacted  by  the  proposed 
application  system.   Its  exact  contents  will  vary 
depending  upon  the  mission  analysis  methodology 
used. 

(6)  Mission  Processes  Model.   This  document  describes 
the  primary  processes  required  to  support  the 
mission  and  includes,  or  expands  on,  the 
processes  by  building  a  model  showing  functional 
processes  by  orqanizational  unit. 

(7)  Information  Model.   This  document  charts  the 
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information  currently  required  to  support  the 
business  processes  and  lists  deficiencies  to  be 
corrected.   It  cross-refers  the  information 
required  to  perform  business  processes  with 
organizations.   It  shows  validation  of  the 
information  presented  with  business  functional 
management  and  business  users. 

(8)    Mission  Weed  Statement  (MNS) . 

(a)  Mission  area. 

(1)      Identify  the  mission  area(s) 

addressed  in  the  MNS.   A  need  may 
be  common  to  more  than  one  mission 
area.   When  this  occurs,  identify 
all  mission  areas. 

(ii)     Describe  current  functional 
organization  and  operational 
environment. 

(ill)     Identify  the  lead  organization  for 
the  application  project,  and 
include  the  reasons  for  selecting 
that  organization  as  the  lead. 

(b)  Mission  need. 

(i)       Describe  the  scope  and  nature  of 
the  mission  deficiency.   Avoid 
describing  the  specific 
characteristics  or  capabilities  of 
a  set  of  hardware  or  an  automated 
system.   Keep  descriptions  in  the 
business  terminology  used  in  the 
functional  area  being  described. 

(ii)      Summarize  the  need  in  terms  of  the 
job  to  be  done  and  the  mission 
results  or  outcomes  to  be 
achieved.   Describe  the  benefits 
to  mission  effectiveness. 
Remember,  a  MNS  describes  a 
deficiency  or  need,  not  a 
solution. 

(c)  Existing  and  planned  capabilities. 
Describe  existing  or  currently  planned  and 
programmed  capabilities  to  perform  this 
mission. 
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(d)  Assessment  of  need.   Evaluate  the  ability 
of  current  and  planned  capabilities  to 
accomplish  the  mission  need.   Base  the 
evaluation  on  one  or  more  of  the  following 
factors. 

(i)      Deficiency  in  existing 

capabilities,  e.g.,  excessive 
manpower,  logistic  support 
requirements,  inadequate  system 
readiness  and/or  mission 
performance. 

(ii)     Obsolescence  of  equipment  or 
software. 

(iii)    Detail  the  short  and  long  term 
effects  of  not  developing  a  new 
system. 

(e)  Constraints.   Identify  conditions  that 
constrain  accomplishment  of  the  mission 
need,  such  as: 

(i)      Timing  of  the  need; 

(ii)     Relative  priority  within  the 
mission  area; 

(iii)    Limits  on  investment  or  recurring 
costs  that  can/will  be  placed  on 
the  alternative  solutions 
evaluated; 

(iv)     Policy  or  organizational 
constraints  placed  on  the 
identification  and  selection  of 
alternatives  to  be  considered; 

(vy      Intraagency,  interagency.  Federal, 
international  standardization 
and/or  interoperability 
requirements; 

(vi)     Potentially  critical 

interdependencies  or  interfaces 
with  other  systems,  new  technology 
or  development  programs; 

(vii)    Logistic  and  manpower 
considerations;  and 
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(yiii)    Security  and  survivability  or 
wartime  considerations. 

B.    Concept  Development  Stage  Documents. 

(1)  System  Objectives.   List  the  major  system 
performance  objectives,  such  as: 

(a)  Reduced  personnel  and  equipment  costs; 

(b)  Increased  processing  speed  (reduced 
turnaround  time) ; 

(c)  Increased  productivity; 

(d)  Improved  manaqement  information  services; 

(e)  Improved  controls  over  automated  decision- 
making systems;  and 

(f)  Compliance  with  laws  and  regulations. 

(2)  Application  System  Architecture.   T'his  document 
IS  an  application  systems  oriented  process  model 
showing  the  sub-systems  required  to  support  the 
missions  described  in  the  mission  analysis.   If  a 
broad  area  is  described,  the  application  system 
may  be  divided  into  multiple  project  modules,  not 
one  large  project.   Each  sub-system  encompasses 
processes  logically  grouped  to  support  major 
parts  of  a  mission. 

(3)  Data  Architecture.  -  T'his  document  is  a  data- 
oriented  model  showing  how  data  should  be 
orqanized  for  maximum  accessibility  to  mission 
processes.   A  well  done  data  architecture  is  the 
key  to  data  sharing,  as  well  as  system  and  data 
base  integration.   It  is  a  blue  print  for  data 
base  design. 

(4)  Data  Communications  Architecture.   This  document 
provides  a  blueprint  of  the  data  communications 
strategy  being  prescribed  in  your  preferred  life 
cycle  strategy.   It  will  describe  what  data  is 
needed  at  each  location  to  be  served  by  an 
architecture. 

(5)  System  Life  Cycle  Strategy.   Develop  a  strategy 
for  fulfilling  system  objectives  that  address 
such  issues  as: 

(a)    In-house  or  contract  support  (0MB  Circulars 
A-76,  Policies  for  Acquiring  Commercial  or 
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Industrial  Products  and  Services  needed  by 
the  Government) . 

(b)  Immediate  vs  long-range  needs  and  planning; 

(c)  Centralized  vs  decentralized  processing; 

(d)  A  comprehensive  system  or  a  partial,  less 
costly  one;  and 

fe)    Conventional,  full-scale  development;  a 
pilot  installation;  or  prototype. 

(6)  System  Milestone  Pates.   Give  an  estimated 
completion  date  for  each  of  the  project 
milestones.   Also,  show  the  projected  elimination 
date  for  the  new  system.   That  is  to  say,  plan 
for  its  removal  from  service  or  replacement  date. 

(7)  System  Life  Cycle  Resources  Estiatate.   Estimate 
the  resources  required  for  each  phase  of  the  life 
cycle  for  the  proposed  strategy.   The  resources 
include  personnel  and  costs  (for  contracts, 
equipment,  etc.).   Like  the  existing  system 
resource  estimates,  these  figures  need  be  only 
accurate  enough  to  determine  whether  the  strategy 
should  be  pursued  to  the  next  phase.   Unlike  the 
mission  analysis,  these  estimates  apply  to  a 
specific  strategy. 

(a)  Alternate  strategies.   In  addition  to  the 
recommended  life  cycle  strategy, 
identifiable  alternatives  must  be 
evaluated.   The  advantages  and 
disadvantages  of  each  are  to  be  stated,  and 
the  reasons  for  not  recommending  them 
given.   Be  succinct. 

(b)  Interim  measures.   Assess  the  immediacy  of 
needs  and  how  they  can  be  met  and 
incorporated  into  the  final  svstem. 

(c)  Impacts  of  project  redirection.   Evaluate 
the  impacts  of  project  redirection  or 
termination  at  each  phase.   Show  the  effect 
on  the  mission,  the  effort  required  to 
return  to  the  previous  system,  and  the 
impact  on  related  activities. 

(8)  Cost/Benefit.  Revise  the  figures  done  in  the 
Mission  Analysis  Stage,  using  the  new  figures 
developed  here.   Is  development  of  the 
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application  cost  justified' 

(9)    Revised  MNS.   Make  any  changes  needed  to  the 

original  MNS ,  and  retain  a  copy  of  the  revised 
version. 

(3  0)   System  Decision  Paper  1.   ^^his  is  a  decision 

document  that  will  help  the  Project  Management 
Committee  to  determine  whether  to  approve 
development  of  an  application  system. 

(a)  Overview.   Address  the  continued  validity 
of  the  MNS  and  briefly  describe  the  need 
for  and  functions  of  the  overall  system. 
Include  key  objectives,  assumptions,  and 
constraints.   Attach  a  copy  of  any  revised 
MNS. 

(b)  Alternatives.   Summarize  system 
alternatives  considered,  the  alternative 
selected,  and  the  reason  for  the 
selection.   Major  costs,  benefits,  savings 
and  risks  for  each  feasible  alternative 
should  be  presented  in  summary  form. 

(c)  Schedule  of  events.   Summarize  major  events 
and  actions  accomplished  in  the  previous 
phase  and  projected  for  the  next  phases  to 
include  estimated  start  and  completion 
dates.   Include  dates  for  critical 
milestone  and  acquisition  events. 

(d)  Resources.   Summarize  resources  (personnel 
and  funding)  expended  to  date,  resources 
needed  for  the  next  phase,  and  projected 
resources  needed  for  the  remainder  of  the 
system's  life.   As  an  appendix,  provide  a 
copy  of  the  budget  exhibits  from  your 
project  file. 

(e)  Acquisition  strategy.   Summarize  the 
proposed  acquisition  strategy  for  each 
element  of  the  project,  including  software, 
ADP  equipment,  data  communications,  and 
services.   Identify  the  proposed  source, 
in-house  or  contract,  and  cost  for  each 
element. 

(f)  Data  communications.   Summarize  the  data 
communications  network  concept  for  the 
selected  automation  alternative.   As  an 
appendix,  provide  the  data  communications 
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section  from  your  project  file. 

(g)    Problem  areas.   Identify  problem  areas  to 
date  or  projected  problem  areas  that  may 
impact  accomplishment  of  objectives. 
Examples  include  inadequate  resources, 
milestone  slippages,  contractual 
difficulties,  etc.   Identify  what  actions 
have  been  taken  or  will  be  taken  to  correct 
the  problem  areas. 

(h)    Preliminary  risk  assessment.   Identify 

threats  to  the  continuation  of  an  automated 
system,  the  financial  impacts  of  these 
threats,  and  recommend  cost  effective 
safeguards.   Recommendation  of  a  back-up 
plan  is  one  response  to  risks. 

(i)    Conflicting  viewpoints.   Based  on  up-front 
coordination  with  the  user  acceptor,  data 
communications  authority  and  ADP  management 
summarize  any  conflicting  viewpoints  and 
show  the  rationale  for  their  rejection  or 
tell  how  they  were  resolved. 

(J)    Approvals.   Identify  what  guidance  is 

needed  from  the  responsible  authorities  and 
what  specific  approvals  are  being  requested 
relative  to  the  SDP.   Express  in  terms 
consistent  with  permission  to  proceed  to 
the  next  milestone  and  AS  development 
/modification/revision  approval,  ADP 
equipement  acquisition  approval,  and  ADP 
services  approval.   Explain  the  mission 
impact  if  the  SDP  is  disapproved. 

3. 2  Development  Phase  Documents. 

A,    System  Analysis  Stage  Documents. 

(1)    Current  System  Description  Document. 

(a)  Mission  summary.   Describe  the  missions 
supported  by  the  current  system. 

(b)  Functional  and  data  summary.   Identify  and 
briefly  describe  the  functions  and  data  of 
the  current  system.   Indicate  those 
functions  and  data  structures  to  be 
absorbed  by  a  new  system.   This  is  a 
general  description.   If  no  current  system 
exists,  explain  the  reasons  for  the  new 


33 


Application  Systems  Life  Cycle  Management  Documents 

Chapter  3 


functions.   a  data  dictionary/directory 
containing  the  data  in  the  current  system 
will  be  created.   Please  note  that  the 
current  system  may  be  manual  or  automated. 

(c)  Responsibilities.   List  the  organizations 
responsible  for  the  various  functions  of 
the  existing  system  and  include  the  number, 
grade,  and  series  of  the  personnel,  and  the 
percentage  of  time  spent  on  the  system. 

(d)  Equipment.   List  equipment  used  by  the 
existing  system  and  indicate  the  portion  of 
time  or  resource  of  that  equipment 
dedicated  to  the  existing  system. 

(e)  Inputs/outputs.   Describe  inputs  and 
outputs,  including  forms,  data  elements, 
media,  geographical  location,  sequences, 
distribution,  volumes,  frequency,  retention 
and  accuracy  requirements  for  the  existing 
system. 

(f)  Processing  procedures.   List  the  sequence 
of  processing  events  for  the  current 
system;  personnel  responsibility;  backup, 
restart  and  recovery  capability; 
calculations  and  manipulations;  and 
equipment  used.   Provide  processing  and/or 
hierarchical  charts.   Describe  both  manual 
and  those  automated  processes,  and  give  a 
distribution  of  the  effort  and  resources 
required  for  each. 

(9)        Control,  Backup,  Security  Summary. 

Document  the  features  in  the  current  system 
that  provide  effective  controls  over  work 
routines,  data  handling,  security  and 
backup. 

(h)    Cost.   Present  a  cost  analysis  that  shows 
the  system  cost  for  current  functions  and 
for  those  that  would  still  be  required. 
Show  costs  for  equipment,  personnel,  etc., 
and  show  costs  by  functions. 

(i)    Deficiencies  and  limitations.   Explain  why 
the  existing  system  can  not  meet  the 
requirements  proposed  or  why  it  is 
inefficient  in  doing  so.   Include 
information  concerning  laws/regulations  or 
policies  not  met  by  the  current  system,  and 
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indicate  why  the  current  system  can't  meet 
current  requirements. 

(2)    Detailed  Functional  Requirements  Document. 

(a)  Performance  objectives.   State  the  reasons 
for  the  system;  specifically,  what  it  will 
accomplish  in  relation  to  the  mission. 
This  information  should  be  derived  from  the 
objectives  listed  during  concept 
development  stage. 

(b)  System  functional  description.   Identify 
and  briefly  describe  each  ma^or  functional 
entity  that  is  needed.   This  list  will  be 
expanded  to  identify  specific  functional 
requirements  and  system  design 
specifications.   If  experimentation  or 
prototyping  are  to  be  done,  explain  the 
potential  benefit.   Justify  all  activities 
which  can  not  be  analysed. 

(c)  Inputs/outputs.   Explain  and  show  examples 
of  the  data  inputs.   Specify  the  format, 
range  of  values,  accuracy,  volumes  and 
sources,  and  develop  data  input  edit 
criteria  where  requirements  are  definite. 
All  I/O  requirements  must  be  sufficiently 
defined  to  permit  development  of  a  system 
design  proposal.   Provide  examples  and 
explanations  of  the  data  outputs  required 
of  the  system.   Include  descriptions  or 
examples  of  hard  copy  reports  (routine, 
situational  and  exception)  as  well  as 
graphic  or  display  reports  and  formats, 
volumes,  distribution,  etc.,  where 
available.   If  unknown,  I/O  requirements 
are  developed  during  the  next  stage. 

(d)  Functional  task.   Show  tasks  {detailed 
processes)  and  data  manipulations, 
including  formulas,  mathematical  processes, 
source  of  input,  transfer  of  output, 
retention  criteria,  and  interfaces  with 
other  functinal  tasks  and  data. 

(e)  Data  characteristics.   Describe  individual 
and  composite  data  elements,  their  related 
coded  representations  (if  already  known) , 
as  well  as  relevant  dictionaries,  and 
complete  a  logical  data  model. 
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(f )  Performance  criteria. 

-  Accuracy.   Mathematical,  logical,  legal, 
transmission. 

-  Validation.   Approach  to  be  taken;  this 
will  not  include  the  details  of  an 
acceptance  and  validation  test. 

-  Timing.   Response,  processing,  data 
transfer  and  transmission  throughout. 

-  Flexibility.   For  changes  in  modes  of 
operation,  ^environment,  interfaces, 
accuracy  and  validation,  and 
enhancements. 

(g)  Interfaces.   Reference  any  existing  systems 
that  must  be  interfaced;  include  hardware, 
data  communications,  and  processing 
requirements  mandated  by  either  manual  or 
automated  systems.   Indicate  the  reason  for 
the  interface  and  any  options  for 
compliance. 

(h)    Failure -contingencies.   Describe  and 

justify  failure  backup  requirements.  (i.e. 
backup  must  be  available  within  24  hours  to 
meet  payroll) . 

(i)    Control,  backup,  security.   Specify  the 

control  security,  backup,  audit  and  privacy 
requirements  to  protect  the  applications 
software,  the  data  files,  and  their 
access.   State  all  requirements  for  system 
access  control  and  auditing,  including 
change  monitoring  and  physical  site 
security. 

(3)    Data  Requirements  Document.   This  document  gives 
a  description  of  the  detailed  data  requirements 
of  the  system. 

(a)  Subject  data  needed.   Summarize  the  subject 
areas  about  which  data  will  be  stored. 

(b)  Data  entities.   Describe  the  data  entities 
and  their  attributes  by  subject  area.   Many 
data  entities  will  be  used  in  more  thanone 
subject  area.   Also,  identify  any  data  in 
the  system  that  will  constitute  "official 
records. " 
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(c)  Logical  data  structures.   Identify  the 
logical  data  structures  (logical  records) , 
that  will  need  to  be  stored  by  the  new 
system. 

(d)  Data  elements.   Identify  and  define  the 
data  elements  to  be  stored  in  the  logical 
data  structures. 

Note:  This  document  should  be  produced  by 
printing  it  as  an  output  from  an  automated 
data  dictionary/directory  system. 

B.    System  Design  Stage  Documents. , 

(1)   Design  proposal. 

(a)  General.   More  than  one  design  may  satisfy 
the  functional  requirements;  select  the 
most  economical  and  efficient  design.   To 
determine  which  alternative  is  best, 
evaluate  each  alternative  against 
preliminary  criteria,  and  then  apply 
further -criteria  to  those  that  still  remain 
as  viable  alternatives.   The  result  of  this 
further  evaluation  determines  which 
alternative  is  the  recommended  Design 
Proposal. 

(b)  Preliminary  evaluation  criteria.   For  a 
design  proposal  to  be  viable  it  should  be 
technically,  operationally,  and 
economically  feasible.   By  establishing 
preliminary  evaluation  criteria  it  may  be 
recognized,  without  a  detailed  evaluation, 
that  some  proposals  are  not  feasible.   Each 
alternative  should  be  evaluated  against  the 
following  list  of  criteria. 

(i)      Cost.   Developmental  and 

operational  costs  for  the  life 
cycle  of  the  system. 

(ii)     Life  cycle.   Development  or 

delivery  time  and  useful  life  of 
the  system. 

(iii)     Flexibility.   Ability  of  the 

design  to  accommodate  changes  in 
policy,  procedure,  environment, 
etc. 
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(iv)      Maintenance.   Requirements  and 
effect  of  the  operation. 

(v)      Operations.   Personnel  and 
facility  to  run  the  system. 

(vi)      Training.   The  level  of  complexity 
and  amount  of  training  required. 

(vii)    Organizational  impact.   Effect  of 
the  design  on  established 
organizational  responsibilities 
and  division  of  functions. 

(viii)    Logistics.   Communications 
requirements  resulting  from 
geographic  of  functional 
separations. 

(ix)     Sensitivity.   Ability  of  the 

system  to  respond  to  changes  in 
volume,  interface,  workload  mix, 
timing,  etc. 

fx)  Complexity.  Interrelation,  such 
as  the  impact  of  one  function  or 
piece  of  equipment  on  others. 

(c)  Alternative  design  proposals.  For  each 
alternative  meeting  the  criteria  of _ the 
preliminary  evaluation,  further  define, 
describe,  and  evaluate  the  following. 

(i)      System  description.   Present  the 
overall  system  concept  and 
describe  how  it  meets  the 
functional  requirements. 

(ii)     Equipment.   Describe  new  equipment 
requirements  and  required  changes 
to  current  equipment. 

(iii)    Software.   Describe  new  software 
requirements  and  needed 
modifications  to  existing 
applications  and  support  software. 

(iv)      Organizations.   Describe 

organizational,  personnel  and 
skill  requirement  changes. 
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(V)      Operations.   Describe  operational 
effects  on  areas  such  as  user 
operating  procedures,  operating 
center  procedures,  operating 
center  and  user  retrieval,  output 
reporting,  and  system  failure 
consequences  and  recovery 
procedures. 

(vi)     Development.   Describe 

developmental  impacts  such  as  user 
support  requirements,  data  base 
development,  system  test 
requirements,  privacy  and  security 
implications. 

(vii)    Site.   Describe  special  building 
modification  requirements. 

(<3)    Recommended  design  proposal.   State  which 
design  is  being  proposed  and  why.   The 
proposal  is  a  definitive  course  of  action, 
and  if  contract  support  is  used,  the 
contract  award  is  recommended,   in 
■  addition,  provide  the  following  for  the 
recommended  Design  Proposal: 

(i)      System  design  Define  the  external 
system  design  in  functional  (i.e. 
user)  terms.   Identify  the 
equipment  type  (not  manufacturer) 
and  the  operating  capabilities 
including  the  specifics  for 
volumes,  capacity,  times,  speed, 
retention,  access,  interfaces, 
,  display  performance,  maintenance 
response,  and  other  technical 
specifications.   Also  identify 
failure  contingencies.   When  the 
design  proposal  is  approved,  this 
information  is  used  to  develop 
specifications  for  acquisition  and 
benchmarking. 

(ii)     Data  model.   Present  a  logical 
model  of  the  data  needed,  and 
their  relationships  and 
attributes.   Complete  a  logical 
design  for  any  data  bases  planned. 

(iii)     Cost  Sensitivity  analysis.   Assess 
the  extent  to  which  costs  and 
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benefits  are  sensitive  to  changes 
in  key  factors  such  as  length  of 
system  life;  volum.e,  mix  or 
pattern  of  workload;  requirements; 
and  configuration  of  equipment  or 
software. 

o  Methodology.   Determine  the 

approach,  assumptions  and  model 
for  the  sensitivity  analysis. 
Use  algorithms  where  possible 
to  develop  sensitivity 
relationships.   Include 
considerations  such  as: 

-  Length  of  system  life.  'Phe 
effects  of  a  shorter  and  or 
a  longer  system  life. 

-  Volume,  mix,  or  pattern  of 
workload.   The  effects  of 
variation  in  the  estimated 
volume,  mix,  or  pattern  of 
workload. 

-  Requirements.   The  effects 
of  potential  changes  in 
requirements  resulting  from 
either  legislative  mandate 
or  changes  in  functional  or 
organizational  structure. 

-  Configuration  of  equipment 
or  software.   'i^he  effects  of 
changes  in  configuration  of 
hardware,  software,  and  data 
communications. 

-  Assumptions.   'T'he  effects  of 
alternative  assumptions 
concerning  objectives, 
requirements,  and 
operations.   Consider  the 
effects  of  alternative 
assumptions  concerning 
inflation  rate;  residual 
value  of  equipment, 
facilities  and  software;  and 
length  of  development. 

o   Sources  of  data.   Identify  the 
sources  of  data,  and  the  method 


m 


Application  Systems  Life  Cycle  Manaqement  Documents 

Chapter  3 


of  data  collection. 

o  Other  factors.   Identify  and 
explain  other  factors  that 
cannot  be  accurately  analyzed, 
but  which  may  qualitatively  or 
quantitatively  affect  the 
assessment  of  costs  and 
benefits  of  one  or  more  of  the 
alternatives. 

(iv)     Risk  analysis.   Take  a 

cost/beneficial  approach  to  avoid 
threats  to  the  system  caused  by 
natural  disasters,  security 
violations,  and  system  failures. 
Justify  costs  for  the  preventative 
actions  specified  in  the 
requirements  and  design  of  the 
system,  including  physical  and  ADP 
security  and  backup.   The 
responsible  functional  management 
participates  in  the  analysis  and 
ensures  that  definitive  action  is 
taken,  both  initially  and 
throughout  the  life  of  the 
system.   The  Office  of  Information 
Resources  Management  furnishes 
guidelines  for  conducting  risk 
analyses,  and  the  Project 
Management  Committee  ensures  that 
they  are  conducted. 

(e)    Rejected  proposals.   Explain  why  each 
alternative  was  rejected. 

(2)    Detailed  Cost/Benefit  Analysis.   T^he  detailed 
cost/benefit  analysis  is  a  valuable  tool  for 
alternative  selection  analysis,  but  it  is  limited 
to  quantif iables  and,  therefore,  should  not  be 
over-emphasized  in  developing  a  recommendation. 
I'his  analysis  is  more  detailed  than  the  analysis 
done  in  earlier  stages,  since  it  is  used  to 
determine  whether  software  development  and 
procurement  is  justified. 

(a)    Costs 


(i)      Non-recurring  costs.   T'hese  are 

one-time  costs  in  the  development 
and  acquisition  process. 
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o  _^i_te.   The  cost  of  erecting  or 
modifying  a  site  and 
surrounding  facilities  to  meet 
the  needs  of  the  proposed 
system,  e.g.,  costs  to  enlarge 
a  computer  room,  and  additional 
space  required  for  personnel 
involved  in  this  process,  etc. 

o  ADP  equipment.   The  cost  for 
hardware,  e.g.,  CPUs,  disk 
drives,  etc. 

o   Data  communications.   The  cost 
for  data  communications 
hardware,  communication  lines 
and  dedicated  data 
communications  software. 

o  Software  purchase.   The  cost 
for  system  software  packages 
procured  for  the  direct  support 
of  the  proposed  system. 

o  Database  developm.ent  T'he  cost 
of  implementing  database  system 
software  and  database 
applications  software. 

o   Software  development.   T'he  cost 
of  implementing  application 
programs. 

o   Studies.   T^he  cost  of  studies 
associated  with  the 
requirements,  design, 
development  or  im.plementation 
of  the  proposed  system. 

o  Conversion.   The  cost  of 
converting  present  data  and 
program  logic. 

o  Procurement.   The  cost  of 

procuring  hardware,  software 
and  data  communications  such  as 
RFP  preparation,  vendor 
evaluation,  and  contract 
preparation. 

o   Trainina.   The  cost  of 

.  I  II  "■ii 

training,  including  user. 
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operations,  and  management 
training. 

°  'travel.   T^he  cost  for  visits  to 
sites  or  regions  outside  the 
main  agency  complex. 

•  o  System  test.   The  cost  of 
evaluating  the  system. 

o  Parallel  operations.   T-he  cost 
of  running  parallel  operations 
for  the  old  system  and  the 
proposed  system.. 

o  Management  overhead.   The  cost 
of  management  interface  in  the 
developm.ent  process  defined  in 
terras  of  hours  required  for 
meetings,  reviews  and 
administrative  functions 
associated  with  continued 
system  operation,  etc. 

(ii)     -Recurring  costs.   These  are  costs 
that  continue  throughout  all,  or 
most  of,  the  system  life. 

o  Maintenance  and  lease  of  ADP 
eauipmenFI   ^^he  cost  for  lease 
and/or  maintenance  contracts 
for  ADP  equipment. 

o  T'imesharing.   The  cost  of 
buying  computer  time  from  a 
commercial  source. 

o  Communications  maintenance. 
The  cost  for  the  rental,  lease 
or  maintenance  of  data 
communications  eauipm.ent, 
services  and  facilities. 

o  Software  maintenance,   t-he  cost 
of  maintaining  application 
software. 

°     Personnel.   The  salaries  and 
fringe  benefits  for  operations, 
data  entry,  and  other  personnel 
assigned  to  the  system.   Part- 
time  activities  should  be 
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prorated  accordinqly. 

o  Training  and  travel.  The  cost 
of  training  and  travel  for  new 
employees  and  upgrades. 

o   Space  occupancy.   The  cost  of 
equipment  space,  personnel  and 
support  facilities,  and 
administrative  offices. 

o   Supplies  and  utilities.   The 
cost  of  both  technical  and 
administrative  supplies. 

o  Security  and  privacy.   The  cost 
of  security  guards,  security 
devices,  etc. 

(iii)    Present  value  cost.   The  total 
annual  cost  can  be  converted  to 
present  value  cost  for  each  year 
of  the  system  Jife.   The  present 
value  will  give  a  more  equitable 
base  when  alternatives  have  a  wide 
dispersion  in  the  funding  years. 
A  percentage  rate  must  be  applied 
to  each  year's  cost  to  calculate 
the  present  value  and  aggregate 
the  total  system  cost.   Refer  to 
FIPS  PUB  64  and  0MB  Circular  A-94 
(revised  March  27,  1982)  when 
present  value  calculations  are 
required. 

fiv)      Non-recurring  benefits,   ^hese  are 
one-time  benefits  that  have  a 
dollar  value.   The  benefits  may 
occur  at  any  point  in  the  life 
cycle,  but  they  are  not  continuing 
benefits.   The  alternative  benefit 
calculation  is  based  on  the 
alternative  (s)  with  which  it  is 
being  compared  (usually  the 
present  system) . 

o  Cost  reduction.   ^he  value  of 
eliminated  owned  equipment 
excessed  eauipment  and 
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inventory,  eliminated  cash-on- 
hand  accounts,  or  any  other 
one-time  source  of  quantifiable 
benefit. 

o  Value  enhancement.   The  value 
of  additional  tangible 
procurements  (depreciable,  not 
consumable)  and  improvements  to 
owned  facilities  and  equipment. 

(v)      Recurring  benefits.   These  are 

benefits  received  throughout  all, 
or  most  of,  the  system  life.   T^hey 
are  quantifiable  with  comparable 
(for  analysis)  the  recurring 
costs, 

o  Maintenance  and  lease  of  ADP 
equipment.   The  savings  for  on 
going  lease  and/or  maintenance 
contracts  for  ADP  equipment. 

o  Communications  maintenance. 

The  savings  on  rental,  lease  or 
maintenance  of  data 
communications  equipment, 
services,  and  facilities. 

o   Software  maintenance.   The 
projected  savings  on  the 
maintenance  of  application 
software. 

o  Personnel .   i^he  salaries  and 
fringe  benefits  saved  (net 
savings)  for  operations,  data 
entry,  and  other  personnel. 

o  Training  and  travel.   Savings 
due  to  less  training  and  travel 
(as  compared  with  other 
systems) . 

o   Space  occupancy.   Savings  on 
equipment  space,  personnel  and 
support  facilities,  and 
administrative  offices. 

o   Supplies  and  utilities. 

Reduction  of  both  technical  and 
administrative  supplies. 
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o  Security  and  privacy.   Savings 
on  security  guards,  devices, 
etc. 

(vi)      Intangible  benefits.   Many 

important  benefits  can  be  received 
from  a  system  without  being  able 
to  easily  quantify  them,  such  as: 

o  Faster  processing; 

o  Lower  error  rate; 

o  Enhanced  organizational  image; 

o  Improved  morale; 

o  Simplified  procedures;  and 

o  Standardization 

These  benefits,  in  many  cases,  can 
be  quantified,  but  not  always 
accurately;  therefore,  they  should 
•  be  .treated  so  as  not  to  distort 
the  analysis. 

(b)   Total  costs. 

(i)      'T'otal  annual  cost.   Total  non- 
recurring and  recurring  cost 
subtotals  for  each  year  of  the 
system  life. 

(ii)     Total  system  life  cost.   Calculate 
the  total  cost  over  the  system 
life  by  summing  the  total  costs 
for  ali  years  of  the  system  life. 

( i i i )     Total  present  value  cost. 

Calculate  present  value  cost  over 
the  entire  system  life  using 
present  value  factors  based  on  the 
discounting  methods  on  0M3 
Circular  A-94. 

(iv)     Residual  value  estimate. 

Calculate  the  remaining  economic 
value  of  ownership  of  all  ADP 
resources  as  of  the  last  month  of 
the  system  life. 
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^^^      Present  value ■ factor .   show  the 

rate  used  for  adjusting  values  to 
present  value. 

(vi)     Discounted  residual  value.   Use 
the  present  value  factor  to 
calculate  the  discounted  residual 
value. 

fvii)    Total  adjusted  cost.   Calculate 
the  ad3usted  cost  by  subtracting 
the  discounted  residual  value  from 
the  total  present  value  cost. 

(c)    ^otal  benefits 

^i5      Annual  tangible  benefits.   Enter 
the  quantifiable  benefits  for  the 
year  of  the  life  cycle  in  which 
the  benefits  are  realized. 

^ii)     System  life  benefit.   Calculate 

the  total  benefit  for  all  vears  of 
.  the  life  cycle. 

^^^^)  Present  value  benefit.   Adjust  "the 

benefits  over  the  system  life 
cvcle  to  their  present  value. 

^iv)     Total  Net  present  value. 

Calculate  the  net  present  value  by 
subtracting  the  adjusted  cost  from 
the  total  present  value  of 
benefits.   See  Part  IV  of  the 
supplement  to  0MB  Circular 
A-76,  the  cost  comparison 
handbook,  for  use  when  contracted 
support  is  being  compared  to 
inhouse  resources. 

f^)  Benefit/cost  ratio.  Calculate  the 
benefit/cost  ratio  by  dividing  the 
total  present  value  of  benefits  by 
the  adjusted  cost. 

^^^)     Payback  period.   Calculate  the 
year  and  month  in  which  the  sum 
(in  current  dollars)  of  benefits 
first  exceeds  the  sum  of  the 
costs. 
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Intangible  benefits  must  also  be 
evaluated  to  decide  whether  the 
proposed  system  should  be 
developed. 

(d)    Advantages  and  disadvantages.   Explain  the 
advantages  and  disadvantages  of  each 
alternative. 

(3)    Revised  Life  Cycle  Strategy.   Information  added 
at  this  time  builds  upon  information  provided  in 
the  Concept  Development  Stage  document  of  the 
same  name. 

(a)  Life  cycle  strategy  summary.   Review  the 
acquisition  strategy  and  development 
approach.   The  acquisition  strategy 
addresses  in-house  and  contract  decisions, 
existing  or  new  equioment  and  services, 
shared  resources,  acquisition  timing, 
resource  sources,  etc.   The  development 
approach  includes  the  system  design  concept 
and  consideration  of  data  base,  centralized 
versus  decentralized  processing,  interfaces 
with  other  systems,  phased  implementation, 
system  flexibility,  and  a  logical 
identification  and  distribution  of 
application  software  responsibilities. 

(b)  Milestones.   List  the  milestones  and  give  a 
short  explanation  of  each  one.   Estimate 
the  completion  date  for  each  one  while 
noting  all  slippages  from  the  prior  stage's 
estimate.   Develop  network  and  project 
planning  charts. 

(c)  Development  T^asks.   Identify  each  project 
task  or  set  of  tasks  which  must  be 
performed  in  order  to  reach  each  milestone 
in  the  system  life.   Include  identification 
of  organizational  and  individual 
responsibilities  for  the  tasks  or  portions 
of  them. 

(d)  Resource  requirements.   Estimate  the 
resources  required  to  perform  each  task. 
The  resource  utilization  should  be 
auditable  at  the  milestone  level  and  will 
be  monitored  to  show  both  estimated  and 
actual  resources  used. 
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fe)    Responsibilities.   In  addition  to  task 

responsibilities,  define  system  ownership 
responsibilities,  system  stewardship 
development  and  operation 

responsibilities.   Define  responsibilities 
for  funding,  submitting  and  approving 
changes,  and  validating  the  system. 

(f)    Schedule.   Prepare  a  schedule  for 

developing  and  implementing  the  system, 
include  time  relationships', 
interdependencies,  critical  path 
identification,  slack  time,  and 
contingencies  for  critical  activities. 
Include  a  schedule  for  document 
preparation.  An  automated  scheduling  svstem 
should  be  used. 

(9)        Contingency  plan.   Evaluate  the  impact  of 

project  plan  changes  to  identify  milestones 
sensitive  to  change,  and  to  estimate  the 
potential  problems  and  their  effects  on  the 
system.   Develop  contingency  plans  to 
resolve  them. 

(4)    System  Decision  Paper  2.   This  paper  can  be 

prepared  by  altering  a  copy  of  SDP  1  to  reflect 
new  information  outlined  below. 

(a)    Overview.   Update  the  SDP  1  overview 

statement  and  discuss  overall  progress 
since  last  milestone. 

fb)  Requirements.  Present  any  significant 
changes  to  the  functional  requirements 
since  Milestone  1. 

(c)  Alternatives.   Summarize  system  design,  and 
the  reasons  for  selecting  the  overall 
system  design.   Significant  changes  in 
costs,  benefits,  savings  and  risks  from 
previous  economic  analyses  should  be 
presented.   Identify  any  significant 
changes  to  functional  requirements  since 
Milestone  1  which  impacted  the  selection  of 
alternatives.   Provide  updated  cost/benefit 
analysis  documentation  from  your  project 
file,  as  an  appendix  to  SDP  2. 

(d)  Schedule  of  events.   Summarize  the  schedule 
of  events  accomplished  in  the  previous 
phase  and  projected  for  the  next  phases. 
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Highlight  changes  made  since  Milestone  1. 

Compare  current  and  previous  schedules  and 

explain  any  overall  schedule  slippaqes 
greater  than  20  percent. 

(e)  Resources.   Summarize  personnel  and  funding 
resources  expended  to  date,  resources 
needed  for  the  next  phase,  and  projected 
resources  needed  for  remainder  of  the 
system's  life.   Compare  current  cost 
estimates,  funded  and  unfunded,  with 
previous  estimates  and  explain  any 
increases  greater  than  20  percent.   As  an 
appendix  to  SDP  2,  provide  updated  budget 
exhibits  from  your  project  file. 

(f)  Acquisition  strategy.   Discuss  the  proaress 
to  date  and  any  changes  regarding  the 
acauisition  strategy  depicted  in  SDP  1.   If 
an  approval  is  required  for  this  action, 
indicate  its  status. 

(g)  Project  logistics 

(i)      Personnel.   Briefly  discuss  action 
taken  to  satisfy  anticipated 
technical  and  functional  personnel 
requirements  for  this  project. 

(ii)      Facilities.   Briefly  discuss 

significant  facility  requirements 
related  to  this  project. 

(h)    Training.   Summarize  training  reauirements, 
costs,  and  how  the  requirement  will  be 
satisfied. 

(i)    Standardization.   Discuss  how  you 

determined  that  no  existing  Department  of 
the  Interior  system  could  satisfy  your 
requirement. 

(j)    Interoperability.   Describe  any 

interoperability  requirement  among  other 
AS  ( s ) . 

(k)    Transition  and  backup  strategy.   Summarize 
the  transition  strategy  from  the  status  quo 
to  the  selected  alternative  and  briefly 
synopsize  your  course  of  action  if  the 
selected  alternative  fails. 
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(1)    Control  and  security.   Provide  a  short 

overview  of  the  control  and  securitv  plan 
regarding  this  application. 

(m)    Privacy.   If  the  proposed  AS  contains 

privacy  data,  summarize  steps  necessary  to 
comply  with  the  Privacy  Act. 

(n)    Software.   Discuss  the  magnitude  of  the 

requirement  for  both  system  and  application 
software.   Explain  how  the  software  will  be 
acquired.   Where  application  software  is  to 
be  converted,  discuss  the  need  for  and 
accomplishment  of  a  software  conversion 
study.   Where  application  software  is  to  be 
newly  developed,  discuss  the  use  of  modern 
software  development  concepts,  such  as 
prototyping  teams,  structured  walkthroughs, 
use  of  standard  high  order  language, 
testing  concepts,  etc.   Ensure  resource 
estimates  associated  with  the  software  are 
clearly  discernible  in  the  cost/benefit 
analysis. 

(o)    Data  communications.   Provide  a  diagram  of 
the  selected  data  communications 
alternative  and  discuss  why  the  proposed 
data  communications  alternative  was 
selected.   Summarize  projected  data 
communications  costs.   As  an  appendix, 
provide  the  data  communications  section 
from  your  project  file. 

(p)    ADP  equipment  configuration.   Provide  a 
diaqram  of  the  proposed  ADP  equipment 
configuration  indicating  relative  size  of 
components.   Where  multiple  sites  are 
involved,  provide  a  diagram  for  a  typical 
site  and  identify  variations  for  other 
sites. 

(q)    Supporting  documentation.   Provide  the 
status  of  all  supporting  documentation, 
including  system  documentation.   Include 
the  status  of  any  hardware  and/or  software 
specifications. 

(r)    Test  and  evaluation.   Synopsize  the 

approach  to  testing  and  evaluation  for  this 
system.   Identify  significant  elements  of 
the  AS  to  be  tested  and  quantify  the 
expected  results. 
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(s)    Problem  areas.   Identify  problem  areas  to 
date  or  projected  problem  areas  that  may 
impact  accomplishment  of  objectives. 
Examples  include  inadequate  resources, 
milestone  slippages,  contractual 
difficulties,  etc.   Identify  what  action 
has  been  taken  or  will  be  taken  to  correct 
the  problem  areas. 

(t)    Conflicting  viewpoints.   Based  on  up-front 
coordination  with  the  user  acceptor,  ADP 
management,  and  project  management 
committee  summarize  any  conflicting 
viewpoints  and  show  the  rationale  for  their 
rejection  or  tell  how  they  were  resolved. 

C.   System  Construction  and  Acquisition  Stage  Documents. 

(1)    System  Test  Plan.   T'his  is  a  plan  for  conducting 
or  monitoring  a  test  of  the  entire  system,   '''his 
plan  will  furnish  the  user  with  the  results  to  be 
evaluated  for  system  acceptance  during  the  next 
stage. 

(a)    Functional  summary.   Describe  the  functions 
of  the  system. 

fb)    Schedule.   Identify  the  time  and  place  for 
the  test.   Identify  participating 
organizations  and  their  responsibility. 
List  the  organizations  and  personnel  that 
develop  the  plan,  conduct  the  test,  review 
the  output,  and  approve  the  results. 

(c)    Test  resources. 

(i)      Equipment.   Show  the  expected 
period  of  use,  types,  and 
quantities  of  the  equipment  needed 
for  the  system  test  that  are  not 
part  of  the  system  being  tested. 

(ii)     Software.   Identify  the  software 
that  is  needed  to  support  the 
testing,  but  is  not  part  of  the 
system  being  tested. 

(iii)    Personnel.   List  the  number  and 

types  of  personnel  to  be  available 
during  the  test  from  both  user  and 
development  groups.   Include  any 
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special  reauirements,  such  as 
multishift  operation  or  key 
personnel. 

(d)  Method  and  constraints. 

(i)      Methodology.   Describe  the  testing 
method  and  strategy. 

(ii)     Conditions.   Specify  the  types  of 
input  to  be  used,  such  as  live  or 
test  data,  as  well  as  the  volume 
and  frequency  of  input,  and 
iterations. 

(iii)    Extent.   Indicate  the  extent  of 
the  testing,  such  as  total  or 
partial . 

(iv)     Data  recording.   Discuss  the 
method  for  recording  the  test 
results  such  as  printouts  or  file 
dumps. 

(v)      Constraints.   Indicate  anticipated 
test  limitations  such  as 
incomplete  or  partial  interfaces, 
equipment,  personnel,  and  data 
bases. 

(e)  Test  materials.   List  materials  needed  for 
the  test  and  their  sources,  such  as: 

(i)      Documentation; 

(ii)     Software  to  be  tested  and  its 
medium; 

(iii)    Test  inputs  and  outputs;  and 

(iv)      Test  control  software. 

(d)    Test  procedure. 

(i)      Control.   Describe  the  test 
control,  such  as  manual, 
semiautomatic  or  automatic 
insertion  of  inputs,  sequencing  of 
operations,  and  recording  of 
results. 
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(ii)      Inputs,   Describe  the  input  data 

and  input  commands  used  during  the 
test. 

(iii)     Outputs.   Describe  the  output  and 
intermediate  data  expected  as  a 
result  of  the  test. 

(iv)     Procedure.   vSpecify  the  step-by- 
step  procedures  for  test  setup, 
initialization,  processing,  and 
termination,  including  test 
progression  or  sequencing. 

(v)      Restart  and  recovery.   Describe 

the  process  for  ensuring  that  the 
system  can  be  restarted  or 
recovered  at  the  designated 
checkpoints. 

(e)    User  acceptance  plan.   Acceptance  planning 
will  be  based  on  satisfaction  of  functional 
and  data  requirements.   Specific  files  and 
values  will  be  determined  when  the  test 
data  design  is  completed.   The  detailed 
validation  process  can  be  finalized  when 
the  system  specifications  are  complete. 
Validation  occurs  during  system  test. 

(i)      Validation  process.   Assign  input, 
process,  and  output  criteria  and 
validation  responsibilities. 
Prepare  data  to  compare  a  manual 
(or  prior)  process  with  the  newly 
automated  process.   People 
responsible  for  va] idation  should 
prepare  a  schedule  of  valid  data 
element  combinations  and  values  to 
check  the  adequacy  of  edits. 
Results  of  all  on-line  transaction 
types  and  batch  runs  will  be 
validated. 

(ii)     Time.   List  throughput  time  and 
sequence  requirements. 

(iii)     Distribution.   List  the 

distribution  centers  for  each 
input  and  output,  including 
transfers. 
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fiv)      Interface.   Show  the 

interdeoendencies  of  processing 
systems  and  the  process  flows 
affecting  the  outputs,  and  the 
procedure  used  to  verify  them. 

(v)      Retention.   Give  file  retention 
requirements  for  successive 
iterations;  show  restart  and 
recovery  points,  and  develop 
criteria  for  satisfactory 
execution. 

(vi)     Process.   Show  the  algorithms  and 
procedures  being  tested. 

(vii)    Volume .   Show  the  technique  used 
to  ensure  adequate  file  sizes  and 
that  volume-dependent  processing 
will  not  saturate  the  system. 

(2)    ADPE  Specifications. 

fa)    Equipment  and  software  performance 

specifications.   These  specifications  are 
for  equipment,  system  software,  and 
utilities,  but  not  application  software  and 
data  communications.   The  specifications 
should  address: 

Run/response  time  per 
message/transaction; 

Throughput  time  for  specified 
volumes  and  processes; 

CPU  memory  size; 

Operating  system  characteristics, 
utilities,  and  compilers; 

Operations  complexity/resources; 

Storage  types  and  volumes; 

I/O  types,  speed,  volumes; 

Security; 

Accuracy/error  detection; 

Interchangeability/compatibility, 
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(xi)      Data  access  methods  and 
procedures; 

(xiil    Backup/recovery; 

(xiii)    Downtime  tolerances; 

(xiv)    Maintenance  response  time  and 
contingencies;  and 

fxv)     Special  performance  criteria. 

(c)    Data  communications  performance 

specifications.   These  specifications 
should  address: 

(i)      Response  time  per 

message/transaction; 

(ii)     Throughput  time  for  specified 
volumes  and  processes; 

(iii)  Terminal  displays/interfaces; 

(iv)  Line  transmission  speed; 

(v)  Transmission  techniques; 

(vi)  Upgrade  capability; 

(vii)  Operations  complexity/resources; 

(viii)  Communications  network  design; 

(ix)  RJE  I/O  interfaces; 

(x)  Security; 

(xi)  Accuracy/error  detection; 

(xii)  Inter changeability/compatibility; 

(xiii)    Traffic 

monitoring/reporting/switching; 

(xiv)     Backup/recovery; 

(xv)      Downtime  tolerances; 

(xvi)     Maintenance  response 

time/contingencies;  and 
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(xvii)    Special  performance  criteria. 
(4)    Application  Software  Documentation. 

(a)  Note  that  all  data  base  and  data  dictionary 
documentation  will  be  stored  in  an 
automated  data  dictionary/directory,   '^his 
will  allow  it  to  be  used  by  auditors, 
system  maintenance  staff  and  functional 
managers. 

(b)  System  and  subsystem  specifications. 
Divide  the  tasks  into  separate  entities  to 
facilitate  preparing  programing 
specifications  and  to  allow  concurrent 
coding  which  reduces  development  time. 
This  also  promotes  modular  testing 
capability  and  aids  in  the  identification 
of  change  requirements  and  throughput 
analysis. 

(i)      Functional  requirements 

grouping.   Identify  criteria  that 
promotes  a  logical  grouping  of 
functional  requirements  into 
separate  entitites  and  establish 
these  groups  as  subsystems. 

(ii)     Interfaces.   Identify  the 

commonality  that  links  each  group 
of  functional  requirements  to 
others  and  show  the  required 
sequencing. 

(iii)     Inputs/outputs.   List  the  inputs 
and  outputs  of  each  subsystem. 
Give  the  origin  of  inputs  and  the 
destination  of  outputs  if  they  are 
to  be  used  by  other  subsystems. 

fiv)     Retention.   Show  data  retention 
requirements  for  inputs/outputs. 

(v)      Performance.   List  any  specific 
subsystem  performance  criteria, 
such  as  accuracy,  validation, 
timing,  and  flexibility. 

(vi)     Operating  environment.   List  any 

restraints  placed  on  the  subsystem 
specifications  that  are  a  result 
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of  the  design  proposal,  such  as 
equipment,  software,  interfaces, 
security  and  privacy,  or  operating 
controls. 

(vii)    Naming  conventions.   Create  naming 
conventions  to  distinguish 
subsystems,  interfaces, 
application  programs,  job  control 
programs,  sorts,  files,  or  other 
identifying  information. 
Establish  names,  numbers  and 
symbol  for  the  subsystems. 

(c)    Data  Base  Documentation.   Describe  the 

logical  and  physical  characteristics  of  the 
data  bases  used  bv  the  system. 

( i )      Logical  characteristics. 

Identify,  define,  and  describe  the 
relationships  among  data  sets, 
records,  and  individual  data 
elements  in  the  system.   Update 
the  logical  data  models  prepared 
earlier. 

(ii)     Physical  characteristics. 

Describe  the  storage  requirements 
for  data,  specific  access  methods, 
and  physical  relationships  of 
access  (index,  device,  area), 
design  considerations,  and  access 
security  mechanisms  for  the  data 
base. 

(iii)    Data  identification.   Identify  the 
system  data  elements  and  state  the 
subsystem  and  interface 
reouirements. 

(iv)     Software/hardware .   List  the 

software  and  hardware  that  will  be 
accessing  the  data,  including  DBMS 
proprietary  software. 

(iii)     Security/privacy.   Specify  the 
data  security  and  privacy 
requirements. 

(iv)      Update.   Show  the  methods  and 
frequency  of  data  updating. 
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fv)      Access.   List  the  data  elements 
for  sorting  and  accessing. 

(vi)     Volume/retention .   Estimate  the 

volume  of  data  to  be  entered  into, 
and  drawn  from,  the  system,  the 
level  of  processing  activity,  and 
data  retention  requirements. 

(vii)    Data  base  construction.   Develop  a 
data  base  design  (data  files  or 
data  management  system) , 
identifying  the  data  files  and 
their  content.   Coordinate  the 
final  product  with  the  detailed 
processing  design  and  program 
specifications. 

(d)    Detailed  process  design.   Identify  the 

tvpes  and  sequences  of  processing  within 
the  subsystems;  identify  the  inputs,  their 
sources,  the  processes  performed  on  them, 
and  the  distribution  and  interface  of  the 
outputs.   The  input  and  output  record 
layouts,  file  names  and  definitions, 
program  names,  and  processing  algorithms 
will  be  coordinated  in  the  data  base  design 
and  program  specifications.   A  project 
manager  may  elect  to  automate  all  of  the 
following  documentation. 

(i)      Subsystem  processing.   Identify 

processing  that  must  be  performed 
within  each  subsystem.   Describe 
the  processing,  its  sequence, 
inputs  and  outputs. 

(ii)     Interface  processing.   Identify 
processing  sequences  between 
subsystems.   Describe  the 
processes,  sequences,  inputs  and 
outputs. 

{ i i i )    Failure/backup  processing. 

Identify  processing  for  backup, 
recovery,  and  restart. 

(iv)     Processing  charts.   For 

application  and  command  language 
programs,  show  the  processing 
relationships  and  sequences;  use 
functional  flow  charts  or 
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processing  charts.   show  the  data 
files  and  specific  elements 
used.   This  information  is  used  to 
develop  the  program 
specifications. 

(v)      Program  identifications.   Identify 
and  name,  using  the  established 
naming  convention,  each 
application  and  command  language 
program  and  state  its  purpose. 
List  the  input  and  output  files 
and  data  elements  to  be  accessed. 

(e)    Program  specifications.   Information  from 
the  svstem  and  subsystem  specifications, 
data  base  design,  and  detailed  processing 
design,  should  be  extensive  enough  that 
specifications  for  each  application  and 
command  program  can  be  made.   A  programer 
should  need  no  additional  information  to 
develop  the  code. 

(i)      Identification.   Give  the  program 
name  and  project  for  which  it  will 
be  used.   Give  the  language  to  be 
used. 

(ii)     Requirements. 

o  Program  description.   Provide  a 
general  description  of  the 
program. 

o  Processing  functions.   State 
the  functions  of  the  proaram  to 
be  developed.   If  the  program 
does  not  fully  satisfy  a 
system/subsystem  function,  show 
the  relationship  to  other 
■  programs  which  aggregately 
satisfy  that  processing 
function.- 

o  Performance .   Specify  the 
performance  requirements. 

o  Accuracy.   Describe  data 

accuracy  requirements  imposed 
on  the  program,  such  as: 


115 


Application  Systems  Life  Cvcle  Management  nocuments 

Chapter  3 


(iii) 


-  Mathematical; 
Loqical; 

-  Legal;  and 

Transmission. 

o  Validation.   Describe  the  data 
validation  reauirements  imposed 
on  the  program. 

o  'T'iminq.   Describe  the  timing 
requirements  imoosed  on  the 
program,  such  as: 

Response  time; 

-  Update  processing  time; 

Data  transfer  and 
transmission  time;  and 

-  Throughput  and  internal 
processing  time. 

o  Flexibility.  Describe  the 
capability  for  adapting  to 
requirement  changes,  such  as: 

Modes  of  operation; 

Operating  environment; 

Interfaces  with  other 
programs; 

Accuracy,  validation,  and 
timing;  and 

Planned  chanaes  or 
improvements. 

Operating  environment. 

o   Equipment.   Identifv  the 

system's  operating  equipment. 
Processor  and  size  of 
internal  storage; 
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■Storage  (on-line  and  off- 
line, media,  form,  and 
devices) ; 

Input/output  devices  (on- 
line and  off-line,  and 
capacities) ;  and 

-  Data  transmission  devices. 

o  Support  software.   Identifv  the 
support  software  and  describe 
any  test  programs.   If  the 
operation  of  the  program 
depends  on  changes  to  support 
software,  identify  the  nature 
and  planned  date  of  these 
changes. 

o   Interfaces.   Describe 
interactions  with  other 
software,  including  sequential 
or  procedural  relationships  and 
data  interfaces. 

o  Storage.   Soecify  the  storaae 


reauirements,  constraints  and 
conditions . 

-  Internal .   Describe  the  use 
of  internal  storage  areas, 
including  indexing  and 
working  areas.   Briefly 
state  the  equipment 
constraints  and  design 
considerations  that  affect 
the  use  of  internal  storage. 

-  Device .   List  by  device  tvne 
all  peripheral  storage 
required,   f^riefly  state 
constraints  im.posed  on 
storage  requirements  by  each 
storage  device.   State 
requirements  for  oermanent 
and  temporary  storage. 

-  Off-line.   Describe  the 
form,  media,  and  storage 
requirements  for  off-line 
storaqe. 
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o  Security  and  privacy. 

Describe  the  security  and 
privacy  reauireraents  for  the 
program,  the  inputs,  and  the 
data  bases. 

-  Controls.   Describe  the 
program  controls  such  as 
record  counts,  accumulated 
counts,  and  batch 
controls.   Identify  the 
sources  of  these  controls. 

(iv)      Design  characteristics. 

o  Operating  procedures.   Describe 
the  operating  procedures  and 
program  functions  or 
reguirements.   Describe  the 
load,  start,  stop,  recovery, 
and  restart  procedures. 
Describe  other  interactions  of 
the  program  with  the  operator. 

o   Inputs .   Give  information  about 
the  characteristics  of  each 
inout  to  the  program,  such  as: 

'T'itle  and  tag; 

-  Format  and  type  of  data, 
such  as  a  record  layout; 

■^T'alidation  criteria; 

Volume  and  freguency; 

-  Means  of  entry; 

Source  document  and  its 
disposition,  or  specific 
interface  source;  and 

Security  and  privacy 
conditions. 

o  Program  logic.   Describe  the 
program  logic.   'T'he  flow  should 
be  presented  in  graphic  form 
(hierarchical  logic  charts, 
Chapin  charts,  flowcharts, 
decision  logic  tables,  etc.). 
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and  supplemented  with 
narratives. 

o  Outputs.   Provide  information 
about  the  characteristics  of 
each  output  from  the  program, 
such  as: 

o  Title  and  page; 

■    '     o  Format  specifications,  such  as 
a  report  format; 

o  Selection  criteria  for  display, 
output,  or  transfer; 

o  Volume  and  frequency; 

-  Output  media; 

Description  of  graphic 
displays  and  symbols; 

-  Security  and  privacy 
conditions; 

Disposition  of  products;  and 

Description  of  display 
seauences  and  contents, 
fixed  and  variable  formats, 
and  display  of  error 
conditions. 

(f)    Test  data  design.   Develop  the  program  test 
data  and  system  test  data  and  create  a 
listing  of  the  test  data  files. 

Test  data  for  each  program  and  a 
comprehensive  test  data  base  are 
required.   Program  test  data  may  be 
furnished  by  the  user,  developed  by  the 
programer,  or  extracted  from  the  system 
test  data  library,  depending  upon  which  is 
most  practical.   The  user  should  design  and 
create  system  test  data.   T'he  items  listed 
should  be  addressed  for  each  set  of  data. 

(i)      Test  conditions.   List  the  purpose 
of  the  test  file. 

(ii)      Preparation  responsibility.   List, 
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by  name  and  organization,  the 
person  who  prepares  the  test  data, 
how  it  is  prepared,  and  in  what 
format  it  will  enter  the  system. 

fiii)    Control.   State  the  procedure  for 
modifying  the  test  data  base. 

(iv)     Negative  data.   Show  the 

conditions  being  tested,  and  list 
the  negative  data  developed  to 
test  these  conditions. 

(v)      Output  recycling.   Identify  output 
generated  from  test  data  that  must 
be  used  for  additional  iterations 
throuqh  the  system,  and  maintain, 
for  comparison,  data  listings  of 
these  fileSc 

(vi)      Data  'listings.   Maintain  a  binder 
of  test  data  listings  for  each 
test  data  file;  include  the  date 
of  the  creation/change.   For 
changed  files,  show  the  change 
that  was  made. 

fg)    Data  dictionary,   ^^he  data  base  design 
defines  the  files  of  the  system  and  the 
detailed  processing  design  specifies  data 
element  processing.   In  order  to  complete 
the  cross-references  and  to  provide  a 
flow/process/interface  for  each  data 
element  through  the  system,  a  data 
dictionary  will  be  prepared.   This 
dictionary  must  be  automated  in  a  data 
dictionary/directory  system.   Printed 
documentation  from  the  data 
dictionary/directory  will  suffice  for  the 
documentation  reauested  here. 

fi)      Data  element  name.   Include  the 

title  of  the  data  element  and  its 
mnemonic  name. 

fii)      Description.   Describe  the  purpose 
.and  meaning  of  each  data  element. 
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(iii)     Source.   Give  the  source  (origin) 
of  the  data  element;  if  calculated 
or  derived,  state  the  processor 
algorithm. 

(iv)     Termination.   Show  all  outputs 

that  contain  the  data  element;  if 
..  one  is  part  of  a  cumulative  or 

;'  •,  ■      derived  result,  show  how  it  was 
processed. 

(v)      Files.   List  all  files  in  which 
the  data  element  appears,   i^his 
includes  temporary  files  and 
history  files.   For  cumulative  or 
processed  files  usina  this  data 
element,  give  the  file  name,  data 
element  number,  and  process  used 
on  the  data  element. 

(vi)     Process.   Show  the  process  and 

sequence  in  which  the  data  element 
is  manipulated  through  the  system, 
including  branching  and  decision 
logic  for  inclusion,  exclusion  or 
termination.   The  data 
dictionary/directory  should  be 
able  to  report  which  programs 
update  each  data  element. 

( 5 )    Control,  Backup  and  Security  Summary. 

(a)    Produce  a  report  that  summarizes  control, 
backup  and  security  features  included  as 
part  of  the  application  system. 

fb)    Topics  covered  by  this  document  will 
include: 

(i)  Validation  processes; 

(ii)  Edit  procedures; 

fiii)  Verification; 

(iv)  Controls  and  data  security; 

(v)  Site  Security;  and 

(vi)      Backup  plans  in  the  event  of  a 
disaster . 
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D.    User  Acceptance  Stage  Documents. 

(1)    System  Acceptance  Report,   '''his  document  records 
the  acceptability  of  the  system  to  the  system 
user.   Custodianship  of  the  system  remains  with 
the  project  manager  at  this  stage. 

(a)    Development  test.   The  development  test  is 
a  preliminary  applications  software  test 
conducted  when  the  developer  completes  the 
system.   It  is  not  a  system  acceptance 
test;  it  is  a  coding  test. 

(i)      Objectives.   List  the  specific 

objectives  of  the  test,  including 
identification  of  the  project, 
subsystems,  job  streams,  and 
programs  in  the  test. 

(ii)     References.   Give  references,  such 
as  previous  test  results. 

(iii)    Responsibility.   State  where  and 
when  the  test  is  performed.   List 
personnel  and  their  duties. 

(iv)     Test  method.   Describe  the  test 
process. 

(v)      Abnormal  conditions.   List  unique 
conditions,  such  as  dummy  files, 
partial  runs,  etc. 

(vi)      Input.   Define  the  input  data  used 
in  the  test. 

(vii)    Output.   Describe  the  data 

obtained  from  the  test  (source, 
type,  limitations,  etc.). 

(viii)    Analysis.   Describe  how  the  test 
results  were  analyzed  and  who 
approved  the  results. 

(ix)      Accomplishments.   Identify 

specific  test  accompl i shments . 

fx)      Problems.   Identify  problems 
encountered, 

(xi)      Action.   List  specific  actions  to 
be  taken,  such  as  accept  test 
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results,  Derform  additional  tests, 
revise  codinq,  etc. 

(xii)     Equipment  used.   T-he  equipment  for 
the  development  test  must  be 
comparable  to  that  intended  for 
permanent  use.   T^he  support 
software,  such  as  compilers, 
operating  systems,  data  base 
managers,  and  utilities  should  be 
copies  of  the  software  that  will 
be  used  permanently.   The  test 
data  is  prepared  by  the  developer. 

(b)    Hardware,  software,  and  data  communications 
acceptance,   i^valuate  the  vendor-furnished 
components  of  the  system  in  their 
environment.   T^his  includes  the  hardware, 
data  communications,  system  software, 
utilities,  compilers,  environmental  factors 
(climate  control  and  security)  ,  and  other 
system  requirements  except  the  data  base 
and  applications  software.   Where 
practical,  separate  acceptance  reports 
should  be  used  for  the  various  segments  of 
the  system,  '^he   test  and  report  are  for 
the  specific  hardware  installed  on  site. 
Unlike  benchmarks,  this  test  does  not 
demonstrate  equipment  type  capability;  it 
tests  the  capability  of  specific  hardware 
and  software,  and  ensures  satisfactory 
performance  of  the  entire  system 
configuration.   Each  piece  of  hardware  and 
software  must  meet  functional  requirements 
and  design  specifications,  and  interface 
properly.   This  test  may  uncover  design 
errors  or  omissions,  as  well  as  deficient 
products.   If  the  entire  system,  including 
applications  software,  is  developed  by  one 
vendor,  this  testing  may  be  included  in  one 
comprehensive  system  test.   Acceptance 
should  include  the  following  activities: 

(i)      T'est  results. 

o  Hardware,  software,  and  data 
communication.   Evaluate  the 
technical  performance  of  these 
items  using  the  criteria 
presented  in  eauipment 
performance  specifications, 
data  communications 
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specification,  and  RFP's. 
Unlike  individual  evaluations, 
however,  emphasis  is  placed  on 
interface  characteristics  such 
as  I/O  and  CPU  time  ratios, 
processinq  mixes,  and 
communications  and  gueuinq 
efficiency.   Also,  evaluate 
volume  (data  and  processinq) 
dependencies,  capacities  and 
system  saturation  points, 
backup,  recovery,  problem 
analysis,  and  abilitv  to 
monitor  the  system  performance. 

o  Fnvircpnment.   Evaluate  the 

facility  according  to  facility 
design  specifications.   T'ests 
for  stress  and  efficiency 
should  be  made  on  such 
requirements  as  power 
(distribution,  surges,  cycle 
and  voltage  fluctuations,  and 
damage  due  to  sudden  losses), 
heat,  air  conditioning, 
humidity,  construction, 
maintenance  access  to 
equipment,  safety,  and 
security. 

o  Applications  software.   T'his  is 
not  a  test  of  the  actual 
software,  but  is  a  test  to 
ensure  that  the  application 
software  will  run  on  the  system 
provided,   '^he  test  ensures 
that  the  operating  system, 
utilities,  compilers, 
communications,  and  hardware 
performs  properly,   ^he 
development  test  data  and 
software  used  bv  development 
personnel  may  be  used.   This 
part  of  the  test  is  not 
necessary  if  the  applications 
software  was  developed  on  the 
permanent  configuration. 

(ii)      Responsibility.   Identify  by  name, 
organization,  and  function,  the 
personnel  who  design,  conduct, 
review,  and  approve  the  test. 
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(iii)     Operation  training.   List  the 
personnel  by  title,  grade,  and 
training  level  who  have  been,  or 
will  be,  trained  on  the  svstem 
operation.   T'his  is  not  the  same 
as  operation  training  for  the 
production  application  software. 
Show  the  vendor  or  other  backup 
sources. 

(iv)      Support.   Identify  system  support 
including  on-site  or  immediate- 
access  vendor  representatives, 
engineering  and  maintenance 
support  (including  preventative 
maintenance  schedules  and  system 
down  contingencies) .   Identify  and 
plan  for  acauisition  of  ADP 
supplies,  such  as  disk  packs, 
tapes,  special  forms  and  paper, 
and  logs. 

(v)      Changes.   Identifv  changes  to  the 
functional  requirements  or 
specifications,  and  show  how  the 
changes  have  been  evaluated. 
Identify  requirements  omitted  or 
improved  during  testing  or  test 
preparation.   Show  how  these 
changes  were  included  in  the 
system. 

(vi)     Action.   List  the  deficiencies  and 
recommendations. 

(c)    Data  base  validation.   The  complete  system 
test  will  verify  the  inclusion  of  all  data 
elements,  test  each  access,  and  ensure  the 
capability  to  accommodate  all  conditions. 
Data  base  validation  measures  the  data  base 
technical  capabilities  aqainst  design 
specifications.   It  also,  bv  using  the  test 
data  base  or  other  validation  data,  ensures 
the  accuracy  of  the  design  specifications 
by  verifying  access  and  manipulation 
requirements.   The  validation  includes: 

(i)      Data.   List  each  data  base,  the 
access  keys,  and  manipulation 
requirements  (this  can  be 
extracted  from  the  data  base 
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(design)  . 

(ii)     T^est  results.   Show  the  test 

design  procedure  for  accessing  the 
data  base  and  validating  the 
design  requirements.   Test  data 
may  be  developed  or  program/system 
test  data  files  may  be  used. 
Summarize  the  test  results. 

(iii)     Responsibility.   Identify  by  name, 
organization,  and  function 
personnel  who  design,  conduct,  and 
review  the  test. 

fiv)     Action.   List  the  deficiencies  and 
recommendations . 

(^)    System  test.   The  system  test  (acceptance 
testing)  is  the  final  evaluation  before  a 
system  becomes  operational.   It  allows  the 
user  to  evaluate  the  acceptability  of  the 
system.   No  development  activities  are  to 
be  performed  after  the  system  test  is 
approved.   Before  the  system  test  is 
conducted  the  development  test,  hardware 
and  software  acceptance,  and  data  base 
validation  must  be  completed. 

(i)      Procedure,  '^he   software  will  be 
transferred  to,  and  secured  at, 
the  production  facility  when  the 
development  organization  believes 
their  efforts  complete,  and  system 
test  can  begin. 

Ideally,  the  system  test  is  to  be 
conducted  by  an  independent  team 
with  development  personnel 
available  as  advisors. 

Evaluate  the  system  according  to 
the  system  test  plan.   This 
includes  generating  specified 
outputs  (file  dumps,  reports, 
etc.).   The  user  is  responsible 
for  verifying  the  output 
accuracy.   System  test  activities 
include: 

(ii)     T'est  evaluation.   Conduct  the 

system  test  under  the  system  test 
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plan.   Document  all  deficiencies 
and  recommend  solutions.   Note 
system  test  plan  changes  and 
include  the  reasons  and 
authorization. 

(ill)    Records.   Maintain  processing  and 
output  records.   Include  run 
sequence  and  time  data;  this  will 
be  used  in  preparing  the  Data 
Processing  Manual,  and  User  and 
Operation  Instructions. 

(iv)      Approvals.   Obtain  the 

approvals/comments/recommendations 
as  .reguired  by  the  System  Test 
Plan. 

(e)    User  acceptance.   System  test  data  is 

designed  to  generate  sequences  and  output 
values  to  be  compared  with  known  results. 
The  user  makes  these  comparisons. 

(i)      Review  materials.   List  the  output 
from  the  system  test  and  the  user 
assigned  to  review  it.   Materials 
reauired  by  the  acceptance  plan 
will  be  reviewed  and  accepted,  or 
correction  action  recommended. 

(ii)     "^ime.   Analyze  the  processing  and 
job  run  time  data,  and  the  output, 
to  determine  time  and  sequence 
dependencies. 

(iii)    T'est  results,   ^'he  test  data  was 
designed  to  generate  values  to  be 
compared  with  manually  determined 
values  (or  those  generated  by  a 
previous  process) .   These  values 
provide  calculation,  manipulation, 
and  processing  accuracy  as 
required  by  the  functional 
requirements  and  program 
specifications.   All  discrepancies 
are  to  be  listed,  including  layout 
formatting,  titles,  and  spelling. 

(iv)      Approvals.   Obtain  the  appropriate 
approvals  for  pass,  fail  or 
conditional  acceptance,  and  a 
deficiency  of  items  that  will  not 
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prevent  system  implementation,  but 
which  must  be  corrected. 

(2)    Implementation  Plan.   This  plan  shows  the 

implementation  steps  and  sequence  to  be  followed. 

(a)  Implementation  strategy.   Based  on  the 
acquisition  strategy,  the  current  system 
(if  one  exists) ,  and  the  project  plan, 
decide:   if  implementation  will  be  phased; 
if  parallel  operations  are  necessary;  if  a 
conversion  is  necessary;  and  the  best 
implementation  method. 

(b)  "^iming.   Determine  when  to  implement  the 
system  based  on  information  such  as  new 
fiscal  year,  policy  effective  date, 
resource  availability.   Develop  an 
implementation  schedule, 

(c)  Responsibility.   Identify  responsibilities 
for  activities  such  as  site  preparation  and 
acceptance,  initial  procurement  of  ADP 
supplies,  and  implementation  coordination. 

(d)  Affected  organizations.   Identify 
organizations  affected  by  the 
implementation  and  notify  them  of  their 
preparation  responsibilities. 

(e)  Operations.   Define  operation  functions; 
estimate  and  commit  resources. 

f3)    Conversion  Plan.   T'he  conversion  plan  shows  the 
process  for  converting  work  done  by  the  existing 
system  to  the  new  system. 

(a)  Existing  functions   Identify  the  existing 
functions  that  will  be  converted  to  the  new 
system. 

(b)  Processing.   Phow  the  present  method  of 
processing,  the  proposed  changes,  and  the 
adjustments  to  the  existing  system. 

(c)  Changes  to  existing  software.   Identify  the 
system  and  application  software  that  will 
still  be  used,  and  the  changes  needed  to 
it. 

(d)  Hardware  and  data  communications.   List 
hardware  and  data  communications  that  will 
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still  be  used  and  specify  what  effect  the 
conversion  will  have  on  it. 

fe)    Files.   Identify  the  files  to  be  used 

and/or  converted,  and  show  retention  or 
resubmission  requirements  based  on 
iterative  processing. 

(f )  Schedule.   Identify  conversion  activities, 
establish  a  schedule,  and  list  the 

■  participating  and  reviewing  personnel  by 
name  and  oqanization. 

(g)  Personnel.   Show  the  number  and  types  of 
personnel  to  be  retrained  or  displaced  by 
the  conversion. 

f4)    User  Training  Plan,   '^his  plan  describes  how 
system  users  will  be  trained  to  use  the  new 
system. 

(a)  Training  plan  scope  and  content.   Identify 
the  equipment,  software,  and  procedural 
training  needed  for  management, 
administration,  development,  user,  and 
operation  personnel. 

(b)  Personnel  training  requirements.   Identify 
training  needs  and  when  the  training  should 
be  conducted. 

(c)  Presentation  methods.   Specify  if  the 
training  will  be  formal  (classroom)  or  on- 
the-job,  and  if  all  similar  training  can  be 
conducted  at  one  time  or  if  it  must  be 
phased. 

(d)  Training  space  and  equipment.   Determine 
the  space  required  for  training,  any 
special  training  equipment,  such  as  audio- 
visual, and  any  technical  support  equipment 
such  as  terminals. 

(e)  Funding.   Identify  training  costs  and 
prepare  a  budget  to  include  instruction, 
materials,  travel,  etc. 

(fj    Training  team.   Identify  the  person (s) 
responsible  for  negotiating  and 
administering  training. 
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f5)    Post  Implementation  Review  Plan. 

fa)    Establish  the  time  for  the  first  post 

implementation  review.   Give  the  estimated 
system  life  and  a  schedule  for  the 
remaining  postimplementation  reviews. 

(b)  A  post  implementation  review  will  be 
conducted  within  6  to  12  months  following 
system  installation  to  ensure  that  the 
system  functions  as  designed. 

(c)  Subsequent  reviews  will  be  conducted  at  50 
percent  and  80  percent  of  the  system's 
life,  but  at  least  every  three  years. 

(6)    Data  Processing  Manual.   The  Data  Processing 

Manual  (DPM)  describes  the  system.   For  larger 
systems,  the  material  will  be  in  several  volumes; 
however,  all  volumes  will  be  in  one  centralized 
library.   Anv  omitted  area  must  be  justified. 
The  DPM  is  the  official  system  documentation,  and 
must  contain  all  changes  and  updates  to  the 
system.   This  includes  specification  changes, 
program  listings,  changes  in  processing  times  or 
sequences,  data  definition  changes,  and  any 
information  relevant  to  a  thorough  understanding 
of  the  system.   The  organization  and  format  of 
the  DPM  will  be  decided  by  the  project  leader, 
and  will  meet  all  applicable  FIPS,  Departmental 
and  Bureau  standards.   The  substitution  of 
automated  documentation  in  place  of  paper 
documentation  is  encouraged.   The  DPM  will 
included  at  least  the  following: 

fa)    Equipment/software  performance 
specifications; 

(b)  Data  communications  performance 
specifications; 

(c)  Facility; 

(d)  System  and  subsystem  specifications; 

(e)  Data  base  design; 

(f)  Detailed  process  design; 

(g)  Program  specifications; 
fh)    Test  data  design; 
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(j)    Applications  software  listings; 

(k)    Run  description  -  also  used  in  the 
Operation  Manual; 

fl)    Post  implementation  review  plan;  and 

(m)    Software  control  procedures. 

f7)   User  Manual.   Because  the  recruirements  for 

systems  vary,  a  single  format  is  not  required. 
The  manual  should  present  in  narrative  and  chart 
form  the  following  information  (justify  omitted 
areas)  : 

(a)  General  information. 

(^)  Summary.   Summarize  the 

application  and  aeneral  mission 
functions  of  the  system. 

(ii)      Environment.   Identify  the  user 

organization  and  facility  in  which 
the  software  is  installed  and/or 
maintained. 

(b)  Application. 

fi)      Description.   Describe  when  and 

how  the  software  is  used,  and  the 
unique  support  provided  to  the 
user  organization,  '^he 
description  includes: 

o  Purpose  of  the  software; 

o  Capabilities  and  operating 
improvements;  and 


fii)      Operation.   Compare  the  operating 
relationships  of  the  functions 
with  the  organization  that 
provides  input  to,  and  receives 
output  from  the  software. 
Describe  security  and  privacy 
considerations.   Include  charts 
with  input  and  output 
responsibility. 

(Hi)  Equipment.   Describe  the 

equipment. 
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^^^)      ■'Structure.   Show  the  structure  of 
the  software  and  describe  the  role 
of  each  component  in  the  operation 
of  the  software. 

(V)      Performance.   Provide: 

o  Quantitative  information  on 
inputs,  response  time, 
processing  times,  and  error 
rates. 

o  Qualitative  information  about 
flexibility  and  reliability. 

f^i)      Data  base.   Describe  data  files 

that  are  referenced,  supported,  or 
kept  current  by  the  software. 
Include  the  purpose  for  each  data 
file  in  the  automated  data 
dictionary/directory. 

^^^^)     Inputs,  processing,  and  outputs. 
Describe  the  inputs,  the  flow  of 
data  through  the  processing  cycle, 
and  the  outputs.   Include 
relationships  among  inputs  or 
outputs  by  using  the  automated 
data  dictionary/directory. 

^*^^    Procedures  and  requirements.   Provide 

initiation  information  and  procedures  for 
preparation  of  data  and  parameter  inputs. 
T'he  scope,  quality,  and  logical  arrangement 
of  the  information  should  enable  the  user 
to  prepare  inputs  and  understand  outputs. 
Describe  error,  recovery,  and  file  query 
procedures. 

^i)       Initiation.   Describe  step-by-step 
procedures  to  initiate  processing. 

(ii)      Input.   Define  the  requirements 

for  preparing  input  data.  T'ypical 
considerations  are: 

o  Conditions  (e.g.,  personnel 
transfer,  out-of-stock) ; 


132 


» 


Application  Systems  Life  Cvcle  Management  Documents 

Chapter  3 


o  Frequency  (e.g.,  periodically, 
randomly,  as  a  function  of  an 
operational  situation) ; 

o  Origin  (e.g.,  personnel 

section,  inventory  control) ; 

o  Medium  (e.g.,  keyboard,  punched 
card,  magnetic  or  paper  tape); 

o  Restrictions  (e.g.,  priority 
and  security  handling, 
limitations  on  files  that  may 
be  accessed  by  this  type  of 
transaction) ; 

o  Quality  control  (e.g.,   - 
instructions  for  checking 
reasonableness  of  input  data, 
action  to  be  taken  when  data 
appears  to  be  in  error, 
documentation  of  errors); 

o  Disposition  (e.g.,  instructions 
necessary  for  retention  or 
release  of  all  data  files 
received,  other  recipients  of 
the  inputs) ;  and 

o  Format  (e.g.,  input  forms  and 
instructions  for  preparation) . 

(iii)    Output.  Describe  the  output 
requirements.   Typical 
considerations  are: 

o  Use  (by  whom  and  for  what 
purpose) ; 

o  Freauency  (e.g.,  weekly, 
periodically,  on  demand) ; 

o  Variations  (modifications  that 
are  available  to  the  basic 
output) ; 

o  Destination  (e.a.,  computer 
area,  remote  terminal); 

o  Medium  (e.g.  ,  printout,  CRT", 
type,  cards) ; 
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o  Quality  control  (e.g., 
instructions  for 
identification,  reasonableness 
checks,  editing  and  error 
correction^ ; 

o  Disposition  (e.g.,  instructions 
for  retention,  release, 
distribution,  transmission, 
priority,  and  security 
handling) ;  and 

o  Format  (e.g.,  output  forms, 
layout,  and  instructions). 

fiv)     Error  and  recovery.   List  error 

codes  and  the  recovery  procedures. 

(v)      File  query.   Give  instructions  for 
initiation,  preparation,  and 
processing  of  a  query.   Describe 
the  Query  capabilities,  forms, 
commands  used,  and  control 
instructions. 

If  the  software  is  queried  throuqh 
a  terminal,  provide  instructions 
for  terminal  operators.   Describe 
terminal  setup  or  connect 
procedures,  data  or  parameter 
input  procedures,  and  control 
instructions.   Reference  related 
materials  describing  query 
capabilities,  languages, 
installation  conventions  and 
procedures,  and  program  aids. 

(8)    Operations  Manual.   Because  the  requirements  for 
systems  vary,  a  single  format  is  not  required, 
'''he  document,  however,  should  present,  in 
narrative  and  chart  form,  the  following 
information  (justify  omitted  areas) : 

(a )    General  information. 

(i)       Summary.   Summarize  the  general 
functions  of  the  software. 

(ii)      Envirbnment.   Identify  the  system 
owner,  developer,  user,  and  the 
computer  facility  where  the  system 
is  installed. 
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(b)    Overview. 

(i)      Software  organization.   Provide  a 
diagram  of  the  inputs,  outputs, 
data  files,  and  seguency  of 
operations  for  the  software.   Runs 
may  be  grouped  by  periods  of  time 
cycles,  by  organizational  level 
where  performed,  or  by  other 
logical  groupings. 

(ii)     Program  inventory.   Identify  each 
program  by  title,  number,  and 
mnemonic  reference. 

(iii)     File  inventory.   Identify  each 

£ile  that  is  referenced,  created, 
or  updated.   Include  the  title, 
mnemonic  reference,  storage 
medium,  and  storage  requirement. 

fc)    Description  of  runs. 

(i)      Run  inventory.   List  the  runs 
possible  and  summarize  their 
purposes.   Show  the  programs 
executed  during  each  run  and 
identify  options  that  must  be 
determined  prior  to  the  run. 

(ii)      Run  progression.   Describe  the 
progression  from  one  run  to 
another.   Show  program  and  cycle 
run  times  and  variations  caused  bv 
data  volumns,  types,  and  input 
media. 

(iii)    Run  description.   Organize  the 
information  for  each  run  into  a 
presentation  which  includes: 

o  Control  inputs.   List  the  run 
stream  control  statements. 

o  Operating  information.   Provide 
operating  information  such  as: 

-  Run  identification; 

Operating  requirements; 

Initiation  method,  such  as 
on  request,  at  predetermined 
time,  etc.; 
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Fstimated  run  time  and 
turnaround  time; 

-  Operator  commands  and 
messages;  and 

-  Contacts  for  problems  with 
the  run. 

o  Input/outPut  files.   Provide 
information  for  files  created 
or  updated  by  the  run,  such  as: 

File  name  or  label; 

Recording  medium; 

~  Retention  schedule;  and 

-  Disposition  of  file. 

o  Output  reports.   For  each 
output  report  provide 
information  such  as: 

Report  identification; 
Medium; 

-  Volume  of  report; 
Number  of  copies;  and 

-  Distribution. 

o  Reproduced  output  reports.   For 
those  reports  that  are  computer 
generated  and  then  reproduced 
by  other  means,  provide 
information  such  as: 

-  Report  identification; 

-  Reproduction  technique; 

-  Dimensions  of  paper  or  other 
medium; 

-  Binding  method;  and 

-  Distribution. 
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o  Restart/recovery  procedures. 
Describe  procedures  to  restart 
the  run  or  recover  from  a 
failure. 

(a)    Nonroutine  procedures.   Provide  information 
about  emergency  or  nonroutine  operations, 
such  as: 

(i)      Switch  over  to  a  backup  svstem; 
and 

(ii)     Procedures  for  turnover  to  ■ 
maintenance  programers. 

(e)    Remote  operations.   Describe  the  procedures 
for  running  the  programs  through  remote 
terminals. 

(9)    System  Decision  Paper  3. 

Note:   If  changes  in  the  project  scope  are 
significant,  re-entering  the  life  cvcle  process 
beginning  with  mission  analysis/project 
initiation  must  be  considered.   Otherwise  update 
the  previous  SDP  overview  statement  and  discuss 
overall  progress  since  the  last  milestone. 

(a)  Alternatives.   Based  on  experience  during 
this  phase,  evaluate  whether  the  selected 
alternative  remains  the  best  course  of 
action  or  whether  changes  should  be  made. 
Summarize  any  changes  made  to  functional 
reouirements  or  system  design.   Significant 
changes  in  costs,  benefits,  savings,  and 
risks  from  previous  milestones  should  be 
presented.   Provide  an  updated  cost/benefit 
analysis  from  your  project  file  as  an 
appendix. 

(b)  Schedule  of  events.   Summarize  major  events 
and  actions  accomplished  in  the  previous 
phase  and  projected  for  the  next  phase  to 
include  estimated  start  and  completion 
dates.   Highlight  changes  made  since 
Milestone  2.   Compare  current  and  previous 
schedules  and  explain  any  overall  schedule 
slippages  greater  than  20  percent. 

(c)  Resources.   Summarize  resources  expended  to 
date,  resources  needed  for  the  next  phase, 
and  projected  resources  needed  for  the 
remainder  of  the  system's  life.   Compare 
current  cost  estimates,  funded  and 
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unfunded,  with  previous  estimates  and 
explain  any  increases  greater  than  20 
percent.   As  an  appendix,  provide  a  copy  of 
the  updated  budget  exhibits  from  your 
project  file. 

(d)  Aquisition  strategy.   Discuss  the  status  of 
project  acquisitions. 

(e)  Configuration  management.   Summarize  the 
accomplishments  m  establishing  a 
configuration  management  plan  for  this 
project,  including  planned  changes  to  the 
configuration  for  the  implementation  and 
maintenance  stages. 

(f)  Logistics. 

fi)      Maintenance.   Discuss  the  status 
of  maintenance  arrangements  for 
ADP  and  data  communications 
equipment  and  software. 

(ii)     Personnel.   Discuss  the  status  of 
personnel  required  to  operate/ 
maintain,  and  use  this  system. 

fiii)    Facilities.   Discuss  the  status  of 
facility  preparation  for  this 
project. 

(g)  Training.   Summarize  the  status  of 
technical  and  functional  personnel  training 
for  this  project. 

(hy    Transition.   Update  the  transition  strategy 
from  Milestone  2 . 

(i)    Security.   Discuss  actions  taken  to 
accommodate  security  requirements. 

(j)   Privacy.   Discuss  actions  taken  to  comply 
with  the  Privacy  Act. 

Ck)    Software.   Discuss  actions  accomplished 
since  the  last  milestone.   Provide  an 
overview  diagram  which  shows  the 
relationship  of  all  major  application 
programs  in  the  AS.   Provide  the  status  of 
each  program.   Identify  costs  expended  to 
date  versus  costs  projected  for  future 
phases. 
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(1)    Data  communications.   Discuss  steps  taken 
to  accommodate  data  communications 
requirements. 

fm)    ADP  equipment  configuration.   Provide  an 
updated  copy  of  the  ADP  equipment 
configuration. 

(n)    Supporting  documentation.   Provide  an 
updated  list  of  all  supporting 
documentation,  including  system 
documentation. 

(o)    T^est  and  evaluation.   Svnopsize  the  results 
of  testing  and  evaluation  for  this 
project.   Include  the  user  acceptor's 
certification  that  the  designed  svstem  is 
adeauate. 

(p)    Problem  areas.   Identify  problem  areas  to 
date  or  projected  problem  areas  that  may 
impact  accomplishment  of  objectives. 
Examples  include  inadequate  resources, 
milestone  slippages,  contractual 
difficulties,  etc, 

(q)        Conflicting  viewpoints.   Rased  on  up-front 
coordination  with  the  user  acceptor,  data 
communications  authoritv,  and  project 
management  committee,  summarize  any 
conflicting  viewpoints  and  show  the 
rationale  for  their  rejection  or  how  they 
were  resolved. 

(r)    Approvals.   Identify  what  guidance  is 

needed  from  project  management  committee 
and  what  specific  approvals  are  requested 
relative  to  this  SDP.   Express  in  terms 
consistent  with  permission  to  proceed  to 
the  next  milestone.   Explain  the  impact  if 
the  SDP  is  disapproved. 

3 . 3  Operation  and  Maintenance  Phase  Documents. 

A.   Implementation  Stage  Documents. 

(1)    Application  Stewardship  Document,   ^'his  is  a  one 
page  document  in  which  the  responsible  functional 
manager  relieves  the  project  manager  of 
stewardship  responsibilities  for  the  application 
system.   Custodianship  will  pass  to  the  ADP 
manager  responsible  for  system  maintenance,  '^he 
person  responsible  for  svstem  stewardship  will  be 
identified  in  this  document,  as  will  the  system  s 
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custodian. 
B.    Maintenance  vStage  Documents. 

( 1 )    Post  Implementation  Review  fPIT^)  Report. 

(a)  Plan,   '^he  PIP  will  ensure  the  application 
software  meets  the  criteria  documented  in 
the  post  implementation  review  plan  during 
the  User  Acceptance  Stage  of  the 
Development  Phase. 

(b)  Minimum  requirements.   All  PIR  reports  will 
review  the  application  system's  actual 
operating  performance  versus  its  planned 
performance  in  the  following  areas: 

(1)  Mission  support. 

(2)  System  scope. 

(3)  Functional  requirements. 

(4)  Change  control. 

(5)  Auditabilitv. 
(61  Operation  cost. 
(7)  Benefits. 

f8)  Security. 

(9)  Contro].s. 

(10)  System  inputs. 

(11)  System  outputs. 

(12)  Processing  accuracy. 

(13)  Data  base  integrity. 

(14)  Documentation. 

(15)  System  management. 

(16)  Risk  analysis. 

(17)  Disaster  recovery  backup. 
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(18)   Cost-benefit  analysis. 
(2)    System  Decision  Paper  4. 

(a)  Overview.   Update  the  previous  overview 
statement  and  discuss  overall  progress 
since  last  milestone.   This  information 
constitutes  a  post  implementation  review. 

(b)  Evaluation.   Summarize  the  results  of  the 
system  effectiveness  evaluation  and 
corrective  action  needed.   The  svstem 
should  also  be  evaluated  in  light  of  new 
technological  advances. 

(c)  Schedule  of  Events.   Summarize  the  events 
accomplished  during  the  previous  phase  and 
those  projected.   Highlight  changes  made 
since  the  last  milestone.   Compare  current 
and  previous  schedules  and  explain  any 
overall  schedule  slippages  greater  than  20 
percent. 

(d)  Resources.   Summarize  resources  expended  to 
date  and  resources  needed  for  the  remainder 
of  the  system's  life.   Compare  current  cost 
estimates,  funded  and  unfunded,  with 
previous  estimates  and  explain  any 
increases  greater  than  20  percent.   As  an 
appendix,  provide  a  copy  of  the  updated 
budget  exhibits  from  your  project  file. 

(e)  Acquisition  Strategy.   Discuss  the  adequacy 
of  the  previous  acquisition  strategy, 
whether  other  acquisitions  are  required  and 
what  preparations  are  being  made  for  future 
acquisitions, 

(f)  Configuration  Management.   Sum.marize 
operational  procedures  for  controlling 
system  changes,  including  ADP  and  data 
communications  equipment,  systems  software, 
and  applications  software. 

(g)  Logistics.   Discuss  adequacv  of  previous 
logistic  support  requirements  and  whether 
any  changes  are  required. 

(h)    'T'raining.   Summarize  the  status  and 
adequacy  of  technical  and  functional 
personnel  training  for  this  project. 

(i)    ADP  Equipment  Configuration.   Provide  an 
updated  copy  of  the  ADP  equipment 
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conf iquration. 

(j)    Supporting  Documentation.   Provide  an 
updated  list  of  all  supporting 
documentation,  including  system 
documentation. 

(k)    Recommended  actions.   Detail  corrective 

actions  that  need  to  be  taken  to  bring  the 
system  into  conformance  with  requirements, 
and  detail  costs  and  implementation 
schedules. 

(1)    Approvals.   Identify  what  direction  is 

needed  from  project  management  committee 
and  what  specific  approvals  are  required 
relative  to  the  SDP .   "^he  decision  at  this 
point  will  be  whether  or  not  to  leave  the 
application  system  in  operation,  and  what 
changes  to  authorize  to  the  operating 
application  system.   Explain  the  impact  if 
SDP  is  disapproved. 
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10.1  Purpose.  This  chapter  defines  policies  and  responsibilities  for  the 
Life  Cycle  Management  (LCM)  of  major  ADP  information  system  projects  in  the 
Department  of  the  Interior. 

10.2  General.  '■  ,  '  . 

A.  The  constantly  increasing  coiplexity  of  ADP  information  systems 
with  corresponding  increases  in  resource  experva itures  requires  the 
establishment  of  standards  to  ensure  that  major  ADP  information  systems  are 
developed,  acquired,  evaluated  and  operated  in  an  efficient  manner,  within 
prescribed  budget  and  schedule  constraints,  and  are  responsive  to  mission 
requirements. 

B.  Accordingly,  the  LCM  process  has  been  established  to  ensure  that 
adequate  management  and  control  mechanisms  are  followed  during  major  ADP 
information  system  projects. 

10.3  Scope.  This  chapter  applies  to  all  bureaus  and  offices  in  the 
Department  of  the  Interior.  It  also  applies  to  conmercial  contractors, 
universities,  other  government  agencies,  etc.  who  provide  information  system 
support  services  to  the  Department.  ,  . 

10 . 4  Definitions. 

A.  ADP  Information  Systgn.  An  organized  combination  of  human 
resources,  ADP  equipment,  software,  and  established  methods  and  procedures 
designed  to  collect,  process  and/or  communicate  data  or  information  for  the 
purposes  of  supporting  management,  administration,  or  other  organization 
mission  or  program  requirements. 

B.  Major  ADP  Information  System.  An  autcxnated  system  that  requires 
special  continuing  management  attention  because  of  its  extreme  inoportance  to 
an  agency  mission;  its  high  developnent,  operation  or  maintenance  costs;  or 
its  significant  impact  on  administration  of  agency  programs,  finances, 
property,  or  other  resources.  A  more  precise  definition  can  be  found  in 
Appendix  1.         - 
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C.  Life  Cycle-  Management  (LCM) .  The  process  for  administering  an  ADP 
information  system  fron  the  identification  of  a  need  through  its  replacement 
or  termination.  This  process  enphasizes  strengthening  early  decisions  which 
shape  the  system's  cost  and  utility. 

D.  ADP  Information  System  Life  Cycle.  The  time  span  between  the 
establishment  of  a  need  for  a  system  and  the  end  of  its  operational  use. 
Overall,  the  system  life  cycle  is  divided  into  a  discrete  number  of  phases 
with  formal  milestones  placed  between  and  during  each  phase. 

E.  Phase .  A  distinct  interval  in  the  life  cycle  of  an  ADP 
information  system,  characterized  by  the  type  of  activity  performed  and  the 
specific  end  products  produced.  System  life  cycle  phases  and  activities  are 
described  in  impend ix.  2. 

10.5  Objectives.  The  objectives  of  ADP  system  LCM  in  the  Department  are 
to: 

A.  Provide  a  structured  mechanism  for  managing  and  controlling  major 
ADP  information  systsn  projects. 

B.  Ensure  proper  and  responsive  communications  among  systan  users, 
managers,  Departmental  senior  management,  and  data  processing  and  11^ 
personnel. 

C.  Ensure  direct  management  accountability  and  responsibility  for  the 
performance  and  effective  control  of  major  ADP  information  systan  projects. 

D.  Provide  close  and  continued  management  involvement  in  all  phases 
of  major  ADP  information  systan  projects. 

E.  Ensure  that  proper  project  management  and  reporting  practices  are 
Qiployed  during  the  conduct  of  major  ADP  information  system  projects. 

10.6  Policy. 

A.  All  Department  of  the  Interior  organizations  will  utilize  a  life 
cycle  management  approach  to  planning,  developing,  acquiring  and  using  ADP 
information  systems. 
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B.  Major  ADP  information  system  projects  and  their  goals  and 
priorities  shall  be  clearly  defined  in  the  Department's  ADP  and 
Teleccmnunications  Five  Year  Acquisition  Plan,  as  described  in  306  124  4. 

10.7  Responsibilities .  .  .•  ■  . 

A.  Information  Resources  Management  Review  Council  (IBMRC) .  The 
IRMRC  has  responsibility  for: 

(1)  Recanmending  to  the  Under  Secretary  bureau/office  requests 
for  initiation  of  new  developnent  or  upgrades  of  major  ADP  information 
systems. 

(2)  Providing  Departmental  leadership  and  guidance  during  the 
life  cycle  of  all  major  ADP  information  system  projects. 

(3)  Reviewing  the  most  significant  milestone  events  and  products 
during  the  life  cycle  of  major  ADP  information  syston  projects. 

B.  Office  of  Information  Resources  Management  (PIR) .  Itie  Director, 
PIR,  has  responsibility  for: 

(1)  Developing  and  maintaining  Departmental  policy  and  Depart- 
mental LCM  Handbooks  establishing  the  minimum  acceptable  LCM  standards 
applicable  to  major  ADP  information  system  projects. 

(2)  Exercising  oversight  concerning  LCM  policy  ijmplementation  in 
bureaus  and  offices. 

(3)  Sutsnitting  to  the  IRMRC,  bureau/office  requests  for  major  ADP 
information  systsn  projects,  together  with  recoimended  alternatives  and/or 
decisions. 

(4)  Interpreting  Federal  and  Departmental  policies  relating  to 
LCM. 

(5)  Coordinating  the  development  and  inplementation  of 
Departmentwide  ADP  information  systems. 
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C.  Assistant  Secretaries.  Each  Assistant  Secretary  is  responsible 
for: 

(1)  Ensuring  that  the  LCM  concept  and  requirements  described  in 
this  chapter  and  in  the  Departmental  LCM  Handbooks,  such  as  the  i^lication 
Systems  Life  Cycle  Management  Handbook,  are  applied  to  all  major  ADP 
information  system  projects. 

(2)  Ensuring  that  major  ADP  information  system  projects  and  their 
goals  and  priorities  are  clearly  defined  in  the  Department's  ADP  ana 
TelecCTimunications  Five  Year  inquisition  Plan,  as  described  in  306  EM  4. 

D.  Heads  of  Bureaus.  Heads  of  bureaus  are  responsible  for: 

(1)  Ensuring  that  the  LCM  process  is  applied  to  all  major  ADP 
systen  projects  within  their  respective  bureaus. 

(2)  Designating  officials  within  user  organizations  to  be 
responsible  for  management  and  control  of  specific  major  ADP  information 
system  projects. 

(3)  Applying  the  ICM  process  to  all  ADP  system  projects  to  the 
maximum  extent  practical. 

10.8  Authority. 

A.  Office  of  Management  and  Budget  Circulars  (A-11,  A-76,  A-94,  A- 
123,  and  A-127) . 

B.  Federal  Acquisition  Regulations  (FAR)  , 

C.  Federal  Information  Resources  Management  Regulations  (FIPMR) . 

D.  Federal  Information  Processing  Standards  Publications  (FIPS  PUB 
38,  64  and  FIPS  PUB  101) . 

E.  44  U.S.C.  chapters  21,  29,  31  and  33  (Records  Management). 

F.  Departmental  Manual  306  DM  4,  365  DM  1,  375  DM,  380  EM  1  and 
403  DM  . 
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10.9  LCM  Hardbooks. 

A.  The  LCM  Handbooks  (Departmental  Manual  Handbooks) ,  coe  of  vrfnich  is 
the  Application  Systems  LCM  Handbook,  contain  reconmended  procedures  for 
inplanenting  the  KM  process.  Copies  are  available  through  the  normal 
source  of  supply  used  to  obtain  Departmental  Manual  Releases. 

B.  The  Director,  Office  of  Information  Resources  Management,  issues, 
amends,  or  revises  the  Departmental  LCM  Handbooks. 
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Major  ADP  Infonnation  System  -  Definition 


An  autonated  system  exhibiting  one  or  more  of  the  characteristics 
listed  below  and  requiring  special  on-going  Departmental  management 
attention:  . 

1.  Directly  affects  the  agency's  ability  to  meet  a  critical  agency  or 
national  mission. 

2.  Involves  a  significant  investment  including  personnel  costs, 
relating  to  development,  operation  and/or  maintenance.  In  this  context,  high 
develc^annent ,  derating  or  maintenance  cost  means  either:   (1)  the  cost  of 
initial  development  fran  conception  up  to  inplementation  exceeds  $1  million 
dollars,  or  (2)  the  cost  of  operating  and  maintaining  the  system  in  any  year 
exceeds  $500,000,  or  (3)  total  life  cycle  costs  exceed  $10  million  dollars. 

3.  Directly  affects  national  security,  or  the  security  and  safety  of 
financial  resources,  people,  or  other  valuable  property  or  assets. 

4.  Directly  affects  the  performance  of  shared  agency  resources,  such 
as  central  ccnpjter  systems  and  caimunication  networks. 

5.  Is  a  Departmentwide  standard  system. 
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Information  Systems  Life  Cycle 
There  are  three  phases  in  the  systems  life  cycle: 

1.  Initiation  Phase 

During  the  initiation  g^ase,  a  preliminary  determination  of 
mission  needs  is  performed  a«a  prospective  strategies  for  meeting 
these  needs  are  identified. 

2.  Develotment  Phase 

During  the  developnent  phase,  the  system's  functional  requironents 
are  specified,  the  system  is  designed  to  meet  the  specifications, 
and  constructed/acquired  and  tested. 

3.  Operation  Phase 

During  the  operation  phase,  the  system  is  iirplemented ,  maintained, 
evaluated,  and  nrdified  as  additional  requirements  arise. 
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1.1  Purpose.  This  Application  Systons  Life  Cycle  Management  Handbook 
describes  the  Department's  management  process  for  the  design,  develonnent, 
implonentation,  and  operation  of  new  major  application  systons. 

1.2  Objectives .  This  handbook  has  six  objectives. 

A.  Establish  a  framework  for  managing  the  life  of  major  application 
systems. 

B.  Establish  control  mechanisms  to  ensure  that  app] ication  systems  are 
developed,  acquired,  evaluated,  and  operated  in  an  effective  manner  and  at 
the  lowest  total  overall  costs. 

C.  Ensure  that  an  application  svsten  (AS)  is  respcaisive  to  user  needs 
by  requiring  user  participation  in  and  approval  of  all  phases  of  the  life 
cycle. 

D.  Identify  individual  roles  and  responsibilities  throughout  the  life 
cycle  and  ensure  managanent  accountability  for  the  success  or  failure  of 
applicaticn  system  actions. 

E.  Provide  visibility  of  all  resource  reguironents  related  to  an 
application  system  for  its  entire  life  cycle. 

F.  Avoid  the  development  of  unneeded  systOTis  by  ensuring  mission 
analysis  is  done  before  a  major  ADP  developnent  project  is  authorized. 

1.3  Applicability,  ttie  standards  set  out  in  this  handbook  apply  to  all 
major  application  systsns  developrent,  acquisition  and  major  enhancements  in 
the  Department  of  the  Interior.  These  standards  are  not  intended  to  be 
applied  retroactively  to  applications  a].ready  under  development.  A  major 
application  system  can  be  identified  by  answering  the  followina  questions  in 
a  yes-or-no  manner  with  regard  to  the  application  system  project  that  is 
being  considered: 

A.  Does  the  proposed  system  directly  affect  the  Department's  ability 
to  meet  a  critical  Departmental,  national  or  international  mission? 

B.  Will  the  total  cost  of  identifyina  requirements  and  developing  the 
application  software  required  to  bring  the  system  into  operation  equal  or 
exceed  $1  million? 

The  cost  thresholds  detailed  in  this  paragraph  assume  that  all  relevant 
costs  of  defining  mission  needs,  and  developing  or  acquiring  the  application 
software  have  been  included.  Relevant  costs  include  direct  and  allocated 
costs  for  hardware,  software,  labor  (in-house  or  contract) ,  and  charges  for 
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computer  processing  time  during  initiation  and  development,  'tie  costs 
incurred  to  operate  a  system,  for  esan^le  new  hardware  or  a  new  data  base 
managensnt  system,  will  be  allocated  to  syston  life  cycle  costs  (see  C)  ara3 
not  cOlocated  as  develc^anent  costs. 

C.  Will  total  life  cycle  costs,  including  the  cost  of  operating  the 
system  exceed  $10  million?  Will  the  annual  cost  of  operating  and 
maintaining  the  system  exceed  $500,000? 

D.  Will  the  system  affect  national  security? 

E.  Will  the  systen  directly  affect  the  security  and  safety  of 
substantial  financial  resources,  people,  or  other  valuable  assets? 

F.  Does  the  system  support  a  major  mission  whose  function  is  multi- 
bureau  in  its  scope  as  is,  for  instance,  the  PAY/PEES  system? 

G.  Does  the  system  directly  affect  the  ability  of  the  Department  to 
perform  a  mission  designated  by  the  President,  Congress,  Office  of 
Managonent  and  Budget,  or  the  Secretary  as  being  of  particular  importance? 

If  the  answer  to  any  of  these  questions  is  "yes",  then  the  application 
system  is  major  and  the  standards  in  this  handbook  acply. 

1.4  Responsibility 

A.  Assistant  Secretaries.  Each  Assistant  Secretary  is  responsible 
for: 

(1)  Ensuring  that  the  LCM  concept  and  requirements  described  in 
this  Application  Systems  Life  Cycle  Management  Handbook,  are  applied  to  all 
major  ADP  information  system  projects. 

(2)  Ensuring  that  major  ADP  information  system  projects  and  their 
cpals  and  priorities  are  clearly  defined  in  the  Departnent ' s  ADP  and 
Telecommunications  Five  Year  Acquisition  Plan,  as  described  in  306  CM  4. 

B.  Heads  of  Bureaus.  Heads  of  bureaus  are  responsible  for: 

fl)  Ensuring  that  the  LCM  process  is  applied  to  all  major  ADP 
system  projects  within  their  respective  bureaus. 

(2)  Designating  officials  within  user  organizations  to  be 
responsible  for  managenent  and  control  of  specific  major  ADP  information 
system  projects. 
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(3)  Applying  the  IHA  process  to  all  ADP  system  projects  to  be 
maximum  extent  practical. 

C.  Program  and  Administrative  Managers.  Program  and  administrative 
managers  who  request  the  development  of  ADP  information  systems  are 
responsible  for: 

(1)  Ensuring  that  major  information  system  projects  they  request 
are  included  in  the  Department's  ADP  and  Telecanmunications  Five  Year 
Acquisition  Plan. 

(2)  Ensuring  that  the  LCM  concepts  and  requirements  described  in 
this  handbook  are  apolied  to  major  ADP  information  system  projects  thev 
request. 

1.5.  Importance  of  Documentation.  Complete,  accurate  and  usable 
documentation  of  the  application  systems  covered  by  this  handbook  is 
essential.  Historically,  ADP  professionals  have  considered  requirsnents, 
computer  program  and  data  documentation  to  be  by-products  of  the  development 
process.  Because  this  handbook  applies  to  major,  critically  important, 
application  systems,  documentation  of  these  systatis  requiranents,  conputer 
programs  and  data  are  important  deliverables  of  the  develonnent  process.  No 
major  application  system  will  be  implemented  without  this  documentation. 
The  documentation  will  be  used  for  system  maintenance,  impact  of  change 
analysis,  management  review  and  control,  system  conversion,  and  audits. 

1.6  Application  Systems  Life  Cvcle  Management. 

A.  Definition.  Application  Systans  Life  Cvcle  Management  is  the 
process  of  administering  an  application  system  over  its  entire  life  cycle. 
Ttie  life  cycle  itself  is  the  time  span  between  the  establishment  of  a  need 
for  a  svstsn  and  the  end  of  its  operational  use.  The  ].ife  cycle  is  divided 
into  discrete,  or  separate,  phases  with  formal  milestones  established  as 
points  for  managanent  control. 

B.  Handbook  Structure.  This  handbook  has  four  chapters. 

(1)  You  are  currently  reading  Chapter  1.  It  provides  an  overview 
of  Amplication  Systems  Life  Cycle  Management,  and  includes  definitions  and 
managenent  responsibilities. 

(2)  Chapter  2  contains  a  description  of  the  life  cycle  of  major 
application  systsns,  and  the  activities  to  be  performed  during  each  stage  of 
the  life  cycle. 

(3)  Standards  for  Project  Managenent,  Reporting  and  Control  are 
described  in  Chapter  3. 
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(4)  Chapter  4  lists  the  minimum  deliverable  dccuitents  that  the 
Department  requires  during  the  life  cycle  of  a  major  application  systen. 
Details  concerning  the  manageirent  of  major  application  systems  in  the 
Department  of  the  Interior  are  given  in  a  technical  document  entitled,  "A 
Project  Manager's  Guide  to  Application  Systens  Life  Cycle  Management."  To 
obtain  a  copy  of  this  document,  contact  the  Director," Office  of  Information 
Resources  Management. 

1-7  Definitions  of  Terms.  This  section  contains  definitions  of  terms  and 
acronyms  used  to  describe  Application  Systems  Life  Cycle  Maxiagement. 
ADPE.  Autonatic  Data  Processing  Equipment. 

ADP  Information  System.  An  organized  ccmbination  of  human  resources,  ADP 
equipnent,  software,  and  established  methods  and  procedures  designed  to 
collect,  process  and/or  canmunicate  data  or  information  for  the  purroses  of 
supporting  management,  administration,  or  other  organization  mission  or 
program  requirements. 

ADP  Information  System  Application.  See  application  systan. 

Application  System.  An  information  system  composed  of  one  or  nore  units  of 
software  supported  by  ADPE  and  automating  work  methods  and  procedures  to 
collect,  store,  process  and  disseninate  infonnation  to  support  specific 
agency  missions. 

Applicatioi  Svsta-ns  Life  Cycle.  The  time  span  betvreen  the  establishment  of 
a  need  for  a  system  and  the  end  of  its  operational  use.  Overall,  the  system 
life  cycle  is  divided  into  a  number  of  discrete  phases  with  formal 
milestones  placed  between  and  during  each  phase. 

AS.  Application  Systan. 

ASLC,  Application  System  Life  Cycle. 

Automated  Data  Processing  Equiment.  Equipment  used  to  execute  conputer 
program  instructions,  provide  input  to  those  instructions,  or  carry  oui^jut 
from  them.  Included  would  be  computer  processing  devices,  data  storage 
devices,  data  terminals,  data  communications  equipment,  and  printing 
devices. 

Concept  Development  Stage.  The  second  stage  in  the  life  cycle  of  a  major 
application  system.  In  this  stage  blueprints  (plans)  are  developed  for  the 
functions,  data  and  data  caimunications  needed  to  fulfill  the  mission 
needs.  These  blueprints  provide  guidance  and  structure  to  the  work  done 
when  the  systan  enters  the  Development  Phase. 

Custodian.  A  person  v*io  guards,  protects,  operates  and  maintains  an 
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application  system  in  accordance  with  a  service  level  agreeinent  with  the 
steward  of  the  arplicatiOTi  system.  The  custodian  of  an  amplication  systen 
is  the  ADP  manager  with  line  respcxisibility  for  providing  time].y  and  cost- 
effective  computing  resources  and  system  maintenance  services.  People  who 
perform  maintenance  programming  are  carrying-out  custodial  functions. 

Developnent  Phase.  The  second  phase  in  the  life  cycle  of  major  information 
systans,  and  major  application  s^^tems.  Develocment  Phase  includes  the 
specif icaticxi  of  functional  and  data  requirements,  construction  and 
acquisition  of  required  software  and  hardware,  and  testing  for  technical  and 
user  acceptability  of  the  new  systsn. 

Implementation  Stage.  The  first  stage  in  the  Operation  Phase  of  a  systan. 
During  Inplementation  Stage  the  application  system  is  turned  over  to  the 
systan  maintenance  staff  (custodians)  by  the  ADP  development  team,  and 
operation  begins. 

Information  Technology.  Such  technical  resources  as  hardware  and  software, 
telecamiunxcations,  micrographics,  reprographics,  office  information  systems 
equipnnent,  and  other  autonaticxi  used  to  address  problems  in  information 
handling,  use,  processing,  storage,  and  management. 

Initiation  Phase.  The  first  pnase   in  the  life  cycle  of  a  major  information 
system.  When  an  application  system  is  being  described  this  phase  results  in 
the  missicai  need  being  described  and  analyzed.  Then,  a  blueprint  is 
developed  for  the  development  or  acquisition  of  software  to  meet  the  mission 
need. 

Interoperability.  A  state  where  two  applicaticm  programs  can  use  canmon 
ccmnunications  media  to  exchange  information  easily  and  precisely  without 
apparent  regard  to  configuration  or  equipment  manufacturer. 

Life  Cycle  Management.  The  process  for  administering  an,  ADP  Information 
Systan  fron  the  identification  of  a  need  through  its  replacanent  or 
termination.  This  process  emphasizes  strengthening  early  decisions  which 
shape  its  costs  and  utility. 

Maintenance  Stage.  The  second  stage  in  the  Operation  and  Maintenance  Phase 
of  a  system's  life  cycle.  During  this  stage  the  application's  operational 
effectiveness  is  maintained  by  maintenance  staff  (custodians) .  Requirements 
for  system  modif  icaticns  are  forwarded  fron  the  responsible  functional  area 
(stewards) . 

Major  ADP  Informatiai  System.  An  automated  systan  that  requires  special, 
continuing  managatent  attention  because  of  its  extreme  in^ortance  to  an 
agency  mission;  its  high  develognent,  operation  or  maintenance  costs;  or  its 
significant  impact  on  administration  of  agency  programs,  finara^es,  property. 
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or  other  resources. 

Major  Application  System.  An  application  systan  which,  because  of  its 
importance  to  the  Department  requires  special,  on-going  management 
attention.  This  inportance  is  a  result  of  the  scqpe  or  inportance  of  the 
missicHis  being  supported,  the  inpact  of  the  system  on  the  financial, 
property  or  personnel  resources  of  the  Department,  or  the  cost  of  the 
syston. 

Milestone  0.  The  first  point  in  time  during  the  life  of  an  application 
system  project  that  reporting  is  required  to  inplenent  management  control  of 
the  project.  This  milestone  occurs  after  the  activities  of  Mission  Analysis 
Stage  are  coiplete,  and  before  Concept  Etevelopnent  Stage  begins.  If  the 
project  manager  reconmends  proceeding  to  the  next  stage  of  the  project,  the 
project  management  camiittee  decides  whether  or  not  to  authorize  the  Concept 
Development  Stage. 

Milestcaie  1.  The  second  point  in  time  during  the  life  of  an  application 
systeu  project  that  reporting  is  required  to  inplonent  managenent  control  of 
the  project.  This  milestone  occurs  after  the  activities  of  Concept 
Developnent  Stage  are  ccmplete,  and  before  Development  Phase  begins.  If  the 
project  manager  reconmends  proceeding  to  the  next  phase  of  the  project,  the 
project  management  cormittee  decides  whether  or  not  to  authorize  the 
development  of  the  proposed  systori,  and  the  Assistant  Secretary  reviews  the 
reccramendation  before  system  c3evelopment  begins. 

Milestone  2.  The  third  point  in  time  during  the  life  of  an  amplication 
system  project  that  reporting  is  required  to  implement  managenent  control  of 
the  project.  This  milestone  occurs  after  the  activities  ofSvsten  Design 
Stage  are  complete,  and  before  System  Construction  and  Acquisition  Stage 
begins. ^  if  the  project  manager  recamiends  proceeding  to  the  next  stage  of 
the  project,  the  project  management  ccmnittee  decides  whether  or  not  to 
authorize  the  acquisition  and/or  construction  of  the  systan  that  has  been 
designed. 

Milestone  3.  The  fourth  point  in  time  during  the  life  of  an  application 
system  project  that  reporting  is  required  to  inplement  management  control  of 
the  project.  This  milestone  occurs  after  the  activities  of  User  Acceptance 
Stage  are  coiplete,  and  before  Inplenentation  Stage  begins.  If  the  project 
manager  reconmends  inplementatia:i  of  the  system,  the  project  managenent 
ccmnittee  decides  whether  or  not  to  authorize  the  inplenentation. 

Milestcne  4.  The  fifth  point  in  time  during  the  life  of  an  application 
systan  pro:!ect  that  reporting  is  required  to  implement  managenent  control  of 
the  project.  This  milestone  occurs  after  the  system  is  in  cperation.  The 
responsible  functional  manager  reconmends  whether  or  not  changes  need  to  be 
made  to  the  applicaticn  system  now  in  operatioi,  and  presents  a  report 
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reviewing  the  degree  to  which  the  operaticxial  system  meets  the  goals 
outlined  in  the  Initiation  Phase.  If  revisions  are  reconmended,  the  project 
management  ccrmiittee  will  decide  whether  or  not  to  authorize  their 
implementation. 

MissiCTi  Analysis  Stage.  The  first  stage  in  the  life  cycle  of  a  major 
applicatiCTi  system.  Mission  Analysis  Stage  includes  the  description  of 
missicxi  needs  for  information  and  information  processing. 

MN5.  Pronounced  "mens".  Ihe  Mission  Need  Statement  document  is  prepared  by 
the  application  planning  team  during  the  Mission  Analysis  Stage.  It 
contains  information  describing  the  need  for  additional  information  and 
informatioi  processing  in  the  workplace. 

Operation  and  Maintenance  Phase.  Hbe  third  phase  in  the  life  cycle  of  major 
informatic»i  systems,  and  major  amplication  systenns.  This  phase  begins  with 
the  implementation  of  the  system  and  continues  as  the  system  is  operated  to 
support  the  missic^i  needs  outlined  in  the  Initiation  Phase. 

Phase.  A  distinct  interval  in  the  life  cycle  of  an  AEP  information  system, 
characterized  by  the  type  of  activity  performed  and  the  specific  end 
products  produced. 

Project.  A  planned  undertaking  that  includes  a  number  of  activities  to 
solve  problems  and  produce  results  for  an  organization. 

Project  Charter.  A  written  understanding  between  the  Project  Manager  and 
the  Project  Management  Committee.  This  charter  is  developed  specifically 
for  each  major  ajrplicatica:!  system  project.  It  sets  forth  the  sccpe, 
objectives,  activities,  team  organization,  responsibilities,  and  the  general 
methods  of  operation.  The  lines  of  authority  and  accountability  are  clearly 
identified. 

Project  Manager.  Individual  responsible  for  coordinating  al].  functions  of 
project  management  and  held  accountable  for  project  perfomence. 

Project  Management  Coitmittee.  Selected  individuals  having  f uncticsial , 
financial,  and  technical  expertise  who  oversee  the  status  and_proqress  of  AS 
projects,  and  approve  expenditures  of  funds.  They  also  oversee  planning  and 
managenent  of  AS  project  resources,  and  provide  reports  to  the  IIMIC  as 
required. 

Project  Team.  Individuals  assigned  responsibilities  for  performing  the 
activities  and  producing  the  products  required  during  an  application  system 
develcpnent  project.  Major  applicatic«  systans  will  have  two  distinct 
Project  Teams;  one  during  the  Initiation  Phase,  and  a  second  team  during  the 
Development  Phase. 
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SpP  1.  System  Decision  Paper  1  contains  an  overview  of  the  application 
plan.  It  is  prepared  by  the  applicatioi  planning  team  at  the  end  of  the 
Initiation  Phase  to  support  a  go/no  go  decision  regarding  starting  the 
Development  Phase. 

SPP  2.  Systen  Decision  Paper  2  contains  an  overview  of  the  detailed  design 
of  the  proposed  application  system.  Hardware,  software,  and  ccmmunications 
opticxis  are  discussed  and  an  approach  is  reconmended.  This  document  is 
prepared  by  the  ADP  developirent  team  at  the  end  of  the  System  Design  Stage 
to  support  a  decision  on  whether  to  construct  the  proposed  systen. 

SPP  3.  System  Decision  Paper  3  ccxitains  a  sumnary  of  the  constructed 
application  syston  and  plans  for  irtplementing  the  system.  It  is  prepared  by 
the  ADP  development  team  at  the  end  of  the  User  Acceptance  Stage  to  support 
a  go/no  go  decision  regarding  system  implementation. 

SPP  4.  System  Decision  Paper  4  contains  an  overview  of  the  effectiveness  of 
the  application  systatt  that  is  in  operation^  It  is  prepared  during  the 
Maintenance  Stage  by  the  functional  manager  with  respcxisibility  for  the 
missic«i  area  being  served  by  the  application  systan.  The  document  supports 
a  decision  regarding  whether  or  not  additional  investment  is  needed  to  bring 
the  systen  into  conformance  with  its  planned  goals. 

Stage .  A  specific  part  of  a  phase  in  the  life  cycle  of  a  major  application 
system.  Each  stage  exists  to  provide  specific  deliverables  in  the  life  of 
the  systan. 

Steward .  One  who  oversees  the  adequacy  of  an  applicaticxTi  system's  support 
of  workplace  functions.  The  steward's  role  includes  management 
accountability  for  the  system's  cost  justification,  the  prioritizing  of 
requests  for  its  alteration,  and  assisting  the  custodian  in  establishing  a 
scheduled  date  to  inplement  a  systen  change  requested  by  the  steward.  Gccd 
managesaent  practice  dictates  that  the  steward  of  a  systen  never  be  its 
custodian,  if  the  system  is  a  major  application  systen.  ProfessicsTal  AEP 
sta£f  should  perform  custodial  functicrts  for  major  systems. 

System  Analysis  Stage.  This  stage  of  an  application  system's  life  cycle  is 
t±e  first  stage  of  the  Develcpnent  Phase.  Detailed  functional  and  data 
requirenents  are  described  and  documented,  itiese  requirements  may  be 
identified  by  formal,  structured  analysis  techniques,  or  by  prototyping 
techniques. 

Systen  Design  Stage.  The  second  stage  of  the  Pevelocment  Phase  in  the 
system  life  cycle.  System  Design  Stage  includes  the  detailed  design  of 
software  and  data  bases  to  support  the  application. 
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System  Construction  and  Acquisition  Stage.  "Hie  third  stage  of  the 
Development  Phase  of  a  system's  life  cycle.  In  this  stage  the  application 
system  is  actually  constructed,  programming  occurs,  and  proprietary 
application  software  packages  (if  required)  are  modified  to  meet  functional 
and  data  requirements. 

User  Acceptance  Stage.  The  final  stage  in  a  system's  Development  Phase.  A 
full  system  test  of  the  application  is  ccntpleted  to  determine  if  the 
syston's  functioning  and  data  are  acceptable  to  the  sys ten's  users.  If  the 
system  is  acceptable  to  the  user,  a  reocmmendation  for  iirplementation  of  the 
sys ton  follows. 

User  Acceptor.  An  individual  appointed  at  the  time  a  system  development 
effort  is  initiated.  The  individual  is  to  monitor  and  coordinate,  fron  the 
user  perspective,  those  systsn  development  projects  in  a  user  area.  The 
User  Acceptor  should  be  considered  for  the  role  of  Project  Manager  during 
the  application  planning  team's  tenure.  The  User  Acceptor  interacts  with 
the  Project  Manager  in  a  "customer-contractor"  relationship  during  the  ADP 
project  team's  tenure. 
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2.1.  Purpose.  The  Application  System  Life  Cycle  (ASLC)  identifies  the 
piiases  in  the  life  of  an  application  systan  (see  Fxhibit  2-1)  and  describes 
wDrk  done  in  the  phases. 

2.2  Objectives  of  ASLC. 

A.  Establish  a  framework  for  managing  the  life  of  maior  apolications 
systems; 

B.  Provide  guidelines  for  the  activities  during  a  systan' s  life; 

C.  Identify  minimum  applications  systems  documentation  requirements; 

D.  Establish  products  that  can  be  checked  during  the  life  cycle;  and 

E.  Define  system  development  responsibilities. 

2.3  Background. 

A*  The  Need  for  Standards.  Information  systems  managers  generally 
admit  that  system  development  projects  often  are  not  completed  on  time,  do 
not  meet  user  requirements  and  are  not  ccmpleted  within  budget.  Most 
failures  are  the  resal.t  of  not  understanding  that  building  major  systems 
requires  a  consistent  management  approach  for  structuring  and  controlling 
the  process.  The  Application  Systons  Life  Cycle  Management  Handbook  is  such 
a  standard. 

.^•.  ASIC  as  the  Solution.  The  ASLC  is  the  set  of  standards  for 
initiating,  designing,  installing,  and  maintaining  aoolications  systems.  It 
provides  a  ccmmon  framework  for  managing  the  svsten  develonnent  and 
maintenance  process  in  order  to  improve  conmunications  among  diverse 
interest  groups,  facilitate  control  of  the  process,  and  specify  the  contents 
of  deliverables.  The  ASLC  addresses  all  tvpes  of  major  arolication  systems 
developnent  work. 

2.4  Responsibilities . 

_  A.  Offices  and  bureaus  will  manage  all  major  aTDp].ication  svstems 
during  the  Development  Phase,  and  provide  maintenance  expertise  in  the 
Operation  Phase. 

_  B.  Functional  program  and  administrative  management  must  administer 
ma3or_ applications  during  the  Initiation  Phase,  and  retain  manaqenent 
oversight  responsibilities  during  the  Developnent  and  Operation  Phase. 

C.  A  Project  Management  Canmittee  provides  executive  management 
throughout  a  major  application's  life  cycle. 
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D.  The  Office  of  Information  Resources  Management  prepares  standards 
for  major  application  systems  management. 

2.5  Project  Request.  The  ASLC  begins  when  someone  identifies  that  a 
deficiency  exists  which  inhibits  an  Interior  agency  froit  effectively  and 
efficiently  meeting  its  mission.  Anyone  can  initiate  an  ASLC  by  notifying  a 
responsib].e  functional  (programmatic  or  administrative)  manager,  and  the 
process  of  initiating  a  project  begins  with  the  preparation  of  a  project 
request. 

2.6  ASLC  Phases.  There  are  three  life  cycle  phases  in  the  ASLC. 

A.  Initiation  Phase 

(1)  Purpose.  In  this  phase  the  mission  need  is  analyzed  to  ensure 
that  a  system  is  needed,  and  to  provide  clear  direction  for  later  phases.  A 
blueprint  for  the  application  is  constructed. 

(2)  Description.  Develop  an  idea  for  a  potential  application 
system.  State  mission  tasks  and  identify  deficiencies.  Perform  a  mission 
analysis  to  determine  the  required  functions  and  data,  and  to  obtain  enough 
data  to  decide  if  the  automation  idea  should  be  pursued  into  the  Development 
Phase.  Outline  the  application  concept,  and  provide  cost  and  benefit 
estimates.  Management  participation  in  the  Initiation  Phase  is  very  high, 
since  determining  if  there  is  a  need  that  justifies  a  system  is  a  managerent 
question.  The  Assistant  Secretary's  approval  of  the  reconmended  concept  is 
required  before  the  Development  Phase  begins. 

(3)  Stages.  There  are  two  stages  in  this  phase. 

o  Mission  Analysis 
o  Concept  Development 

B.  Developnent  Phase. 

(1)  Purpose.  In  this  phase  the  application  system  is  constructed, 
tested,  and  documented.  Detailed  requirenents  definition  occurs  early  in 
this  phase. 

(2)  Descripticn.  Define  the  functional  requirements  in  enough 
detail  to  determine  system  and  software  specifications.  Then,  identify  the 
data  requirements,  establish  performance  criteria  and  determine  interfaces 
to  other  systans.  Follow  the  National  Archives  and  Records  Administration 
standards  for  records  creation,  documentation  and  disposal. 

Working  with  in-house  or  contract  staff  create  a  definitive  design  proposal 
for  develoTinent,  or  a  prototype  for  experimentatiai.  Also,  prepare  a 
detailed  cost/benefit  analysis  for  the  new  design.  During  system 
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construction  acquire  and  install  the  hardware,  data  ccmnunications  and 
proprietarv  software  needed.  The  application  software  is  developed  and 
undergoes  unit  and  technical  testing  before  system  acceptance  testing  takes 

.system  (user  acceptance)  test  is  performed  to  determine  if  the  systan's 
functionality  and  data  are  acceptaW.e  to  the  user,  -rhe  users  of  each  type 
of  documentation  wi].l  sign-off  on  the  documentation  when  thev  find  the 
documentation  prepared  by  the  project  team  is  adequate.  The" project  team 
corrects  any  deficiencies  found  in  the  documentation.  User  training 
material  is  finalized,  and  operation  instructions  are  orepared. 

(3)  Stages.  Develonnent  Phase  has  four  stages. 

o  System  Analysis  (prototyping  may  be  substituted) 

o  SvstQn  Design 

o  Construction  and  Acquisition 

o  User  Acceptance 

•C.  Operation  and  Maintenance  Phase. 

^^  4=   ■ir.-.i-'-L  ^HEE2S£-  In  this  ohase  the  system  is  brought  into  operation 
to  fulfill  the  requirements  for  which  it  was  constructed. 

,  .  ^.   ^2)  Description.  Operate  the  system  to  accomplish  the  Droduction 
obiectives  for  which  it  was  designed.  Run,  change,  or  repair  the  system  as 
necessary.  Prepare  resource  utilization  and  efficiency  reports  and  conduct 
periodic  post  implementation  reviews  to  ensure  that  the  system  still 
efficiently  meets  requirements. 

(3)  Stages.  Operation  and  Maintenance  phase  has  two  stages, 
o  Implementation 
o  Maintenance 

2.7^e_^_Standards.  Use  this  ATX)lication  Systems  Life  Cvcle  Management 
Handbook  when  developing  major  applications  systems  in  addition  to  the 
Federal  Information  Processing  Standards  (FIPS  PUB)  Guidelines,  numbers  38 
and  64,  ADP  audits  are  to  be  conducted  to  ensure  comDliance. 

2*^  Doc^ent  Retention.  The  Project  Manager  retains  all  documentation 
required  as  a  part  of  ASDC  in  a  Project  Pile.  A  copy  of  these  documents  is 
turned-over  to  the  functional  manager  (steward)  who  is  accountable  for  the 
application  systan.  The  documents  are  important  records,  and  will  be 
archived  after  an  application  system  is  discarded  or  replaced. 
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Data  in  systems  containing  records  created  and  maintained  in  electronic  and 
magnetic  media  will  be  retrievable,  protected  from  unauthorized  disclosure, 
and  disposed  of  only  in  canpliance  with  approved  records  disposal 
schedules.  See  44  U.S.C.  Chapter  33. 
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3.1  Purpose.  This  chapter  establishes  minimum  standards  for  project 
management  and  reporting  when  a  major  application  systen  is  being 
developed.  These  standards  oily  apply  to  applicaticai  systems  that  are 
deened  to  be  "major"  under  the  guidelines  of  this  handbook.  See  306  DM  3  or 
bureau  standards  for  project  management  standards  applicable  to  systems  not 
covered  by  this  directive. 

3.2  Objectives. 

A.  Ensure  the  projects  for  developing  major  application  systens  have 
standards  that  recognize  the  unique  characteristics  of  major  systems; 

B.  Coordinate  project  management  with  the  Application  Svsten  Life 
Cycle  (Chapter  2);  and 

_  C.  Ensure  adequate  management  control  and  review  mechanisms  exist  when 
major  application  systems  are  developed,  so  that  syston  costs  and  benefits 
are  thoroughly  documented  and  reviewed  by  management. 

3.3  Applicability.  This  standard  applies  to  all  work  which  leads  to  the 
implementation  of  a  major  application  syston  as  defined  in  paragraph  1.3  of 
this  handbook. 

3.4  CGnponents.  The  three  major  components  of  project  management, 
reporting  and  control  are  the  organization  and  management  of  the  project, 
the  management  controls  placed  upon  the  project,  and  the  reporting  required 
to  enforce  the  management  controls. 

A.  Project  organization  and  management  will  reouire  that  project  teams 
be  formed  to  perform  the  life  cvcle  activities  mentioned  in  Chapter  2  of 
this  handbook.  Because  of  the  size  and  importance  of  major  applications, 
two  distinct  project  teams  will  be  involved  in  a  major  application  system.' s 
life  cycle. 

(1)  Application  Planning  Team,  itiis  team  will  be  formed  to 
canplete  the  activities  listed  as  part  of  the  Initiation  Phase,  ^eam 
members  will  be  from  the  functional  area  sponsoring  the  automation  project, 
since  the  work  to  be  done  in  this  phase  focuses  upon  the  functional  area's 
work  needs. 

. (2)  ADP  Development  Team.  This  team  will  build  upon  the  work  of 
the  application  planning  team,  and  canplete  the  activities  that  form  the 
Development  phase.  Soneone  experienced  in  project  management  should  be 
Pro:]ect  Manager  of  this  team. 

B.  Management  controls  include  the  handbook  you  are  now  reading,  and 
the  structures  it  mandates  to  provide  management  oversight  of  the 
application  systan  as  it  progresses  through  its  life  cycle.  There  are  two 
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bodies  that  directly  review  and  exercise  manageinent  oversight  of  the 
application  develotment  and  acquisition  process. 

(1)  Project  Management  Ccmmittee  (PMC) .  '^e  IWC  will  review  the 
reports  of  the  Project  Manager  at  each  milestone  and  make  a  go/no  go 
decision  with  regard  to  the  next  stage  of  the  life  cycle.  The  PWC  should 
require  the  Project  Manager  to  report  progress  periccSically  between 
milestones . 

(2)  IBMRC.  This  Departmental  executive  ccmmittee  has  been 
convened  by  the  Under  Secretary.  Composed  of  the  Under  Secretary  and 
representatives  of  the  bureaus,  this  group  reviews  the  progress  of  major 
application  system  projects,  '^e  Project  Manager  is  responsible  for  meeting 
the  reporting  required  by  the  IPMRC. 

C.  Major  applicaticai  systen  projects  will  report  their  progress  at 
predetermined  milestones  in  the  life  cvcle.  Manaaejnent ' s  explicit  approval 
is  needed  at  each  milestone  before  the  project  can  proceed  beyond  that 
milestone.  Rigorous  enforcement  of  these  reporting  requirements  by 
management  authorities  will  mitigate  the  chances  of  a  major  arolication 
system  failure  late  in  the  system  life  cvcle.  "Tliis  will  allow  applications 
that  are  "off-track"  to  be  corrected  before  they  become  m^jor  problens. 
Reporting  is  required  to  the  Project  Manageinent  Conmittee  at  each  of  the 
following  milestones. 

(1)  Milestone  0,  Milestone  0  occurs  after  the  Mission  AnaJ.ysis 
Stage  and  prior  to  the  Concept  Development  Stage  during  the  Initiation 
Phase.  The  Application  Planning  Team  is  responsible  for  meeting  these 
reporting  requirements. 

(2)  Milestone  1.  Milestone  1  occurs  after  the  Concept  Development 
Stage  and  prior  to  the  System  Analysis  Stage.  The  Application  Planning  Team 
is  responsible  for  meeting  these  reporting  reouirements. 

(3)  Milestone  2.  Milestone  2  occurs  after  the  System  Design  Stage 
and  before  the  System  Construction  and  Acquisition  Stage.  The  ADP  project 
team  is  responsible  for  meeting  these  reporting  requirements. 

(4)  Milestone  3.  Milestone  3  occurs  after  the  Development  Phase 
and  prior  to  placing  the  AS  in  operation.  The  ADP  project  team  is 
responsible  for  meeting  these  reporting  requirements. 

(5)  Milestone  4.  Milestone  4  occurs  after  the  A5  has  been  put  in 
operaticxi.  The  functional  manager  is  responsible  for  meeting  these 
reporting  requirements. 
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Chapter  3   Project  Manaqement,  Reporting  and  Contro],  3.5 

3.5  Details.  Detailed  infonration  regarding  Project  Manaqenient,  Reporting 
and  Control  can  be  obtained  by  contacting  the  Office  of  Information 
Resources  Management  and  requesting  a  copy  of  "A  Project  Manager's  Guide  to 
i^lication  .Systens  Life  Cycle  Management." 
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COST/BENEFIT 
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CURRENT 

SYSTEM 

DESCRIPTION 

DETAILED 
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APPLICATION 

SOFTU«?E 

0OCW1ENTATION 

SYSTEM 
TEST  PLftH 

CONTRa, 

BACKUP. 

e  SECURITY 

SUMMARY 


IMPLEMENTATION 
PLAN 

CONVERSION 
PLAN 

USER 

TRAINING 

PL/« 

PIR  PLAN 

DATA  PROCESING 
MANUAL 

USER  MANUAL 

OPERATIONS 
MANUAL 
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POST 
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SYSTEM 
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*  SYSTEM  ACCEPTANCE  REFERS  TO  FUNCHONALITY  AND  DATA  ACCEPTABILITY, 
NOT  SYSTEM  STEWARDSHIP. 

EXHIBIT   4-1 
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Chapter  4  Application  Systans  Life  Cycle  Management  Documents         4.1 

4.1  Purpose .  This  chapter  lists  the  docun\ents  required  during  the  life 
cycle  of  a  major  arplication  systan.  The  documents  are  presented 
chronologically.  While  additional  documents  will,  in  a].l  likelihood,  be 
required  by  individual  projects,  this  chapter  lists  the  minimum  documents 
required  for  project  documentation,  reporting  and  control.  Please  note  that 
all  docunsits  marked  with  an  asterisk  (*)  need  not  be  prepared  exactly  as 
outlined.  Project  managers  should  be  prepared  to  justify  why  a  particular 
dociinait  was  not  prodiaced,  as  will  be  the  case,  for  exanple,  if  a 
prototyping  methcdology  is  used  to  replace  the  System  Analysis  Stage.  The 
substance  required  by  these  dccisnaits  will  be  required,  but  variatiOTis  will 
be  approved  c^  a  case-by-case  basis,  Bocrsn^its  rK>t  marked  with  an  asterisk 
will  be  required  for  all  projects. 

4.2  Initiation  Phase  Documents. 

Project  Request 
Mission  Analysis  Methodology 
Cost/Benefit  Analysis 
Project  Charter 
Organization  Model 
Mission  Process  Model 
Information  Model 
Mission  Need  Statement 

*  Systan  Objectives 

*  System  Architecture 

*  Data  Architecture 

*  Data  Canmunications  Architecture 
System  Life  Cycle  Strategy 
System  Milestone  Dates 

System  Life  Cycle  Resources  Estimates 
Revised  Cost/Benefit  Anal vs is 
Revised  Mission  Need  Statement 
System  Decision  Paper  1 

4.3  Developnent  Phase  Documents. 

*  Current  System  Description 

*  Detailed  Functional  Requirements 

*  Data  Requirements 
Design  Prcposa]. 

Detailed  Cost/J^nefits  Analysis 
Revised  Life  Cycle  Strategy 
System  Decision  Paper  2 

*  ADPE  SpecificatiCTis 

*  Application  Software  Documentation 
System  Test  Plan 

System  Acceptance  Report 
Implementation  Plan 
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*  Conversion  Plan 

*  User  Training  plan 
Post  Implementation  Review  Plan 
Data  Processing  Manual 

*  User  Manual 

Control,  Backup  and  Security  Summary 

*  Operations  Manual 
System  Decision  Paper  3 

4.4  Operation  and  Maintenance  Phase  Documents. 

Application  Stewardship  Document 
Post  Implementation  Review  Report 
System  Decision  Paper  4 

^•^    .2lMil£-  Detailed  descriptions  of  the  contents  of  each  document  can  be 
obtained  by  contacting  the  Office  of  Information  Resources  Management 
and  requesting  a  copy  of  "A  Project  Manager's  Guide  to  Application 
Systems  Life  Cycle  Managonent." 
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